2 ms·

Are you planning to run R in production, or is it purely for research that then gets translated to haskell?

zygomega 14y ago
I see the research as production. There's an autonomous system processing the event stream and deciding on trades that's hands free. I see that as a haskell codebase with C speedups for critical stuff, with no R anywhere to be seen. But then I see a wrapper piece that reports to humans about what's going on within the system. I see R as a great visualization tool for that. I've had good success so far with using R as a fast column database, solving big data hassles, but there may be better solutions in that space.
- boothead 14y ago
  I've had a quick read through the .org file now and it appears that you're using R for things like moving averages over the stream of prices. Have you considered using one of Haskell's FRP (or pipes/conduit) libraries for this side of things?
  - zygomega 14y ago
    definitely. I intend to move all of that code into haskell once I get a handle on whether the algo design is on the right track.
boothead 14y ago
Replying here as I can't add on another reply below The way we do our monitoring/UI is with zeromq/protocol buffers as an external surface to the trading system (basically a PUB socket) and a very thin bridging and translation layer to WebSockets and JSON in python. That way you get to use d3 or anything else on the front end. We use backbone, knockback and d3 with coffeescript.
- zygomega 14y ago
  Sounds great, but way beyond either my paygrade or budget.
- jmandzik 14y ago
  Thatsvery similar to what I/we use to build our realtime network monitoring tools, swapping out python for PHP (regrettably). It's validating to see other shops in different industries zeroing in on the similar stacks.
  - boothead 14y ago
    Yes realtime over websocket to a data-binding style library like knockout (I'd probably choose angular if was starting now) saves you a ton of work.
  - tmzt 14y ago
    Are you using ReactPHP for the ZMQ/webSocket parts or something else?

I see the research as production. There's an autonomous system processing the event stream and deciding on trades that's hands free. I see that as a haskell codebase with C speedups for critical stuff, with no R anywhere to be seen. But then I see a wrapper piece that reports to humans about what's going on within the system. I see R as a great visualization tool for that. I've had good success so far with using R as a fast column database, solving big data hassles, but there may be better solutions in that space.

boothead 14y ago
I've had a quick read through the .org file now and it appears that you're using R for things like moving averages over the stream of prices. Have you considered using one of Haskell's FRP (or pipes/conduit) libraries for this side of things?
- zygomega 14y ago
  definitely. I intend to move all of that code into haskell once I get a handle on whether the algo design is on the right track.

boothead 14y ago

Replying here as I can't add on another reply below The way we do our monitoring/UI is with zeromq/protocol buffers as an external surface to the trading system (basically a PUB socket) and a very thin bridging and translation layer to WebSockets and JSON in python. That way you get to use d3 or anything else on the front end. We use backbone, knockback and d3 with coffeescript.

zygomega 14y ago
Sounds great, but way beyond either my paygrade or budget.
jmandzik 14y ago
Thatsvery similar to what I/we use to build our realtime network monitoring tools, swapping out python for PHP (regrettably). It's validating to see other shops in different industries zeroing in on the similar stacks.
- boothead 14y ago
  Yes realtime over websocket to a data-binding style library like knockout (I'd probably choose angular if was starting now) saves you a ton of work.
- tmzt 14y ago
  Are you using ReactPHP for the ZMQ/webSocket parts or something else?