3 ms·

Yes we agree on library part. Copypasting management code is extremely annoying and also leads to version control hell. I hope this will be changed at some poin

by mikkom 10y ago

Yes we agree on library part. Copypasting management code is extremely annoying and also leads to version control hell. I hope this will be changed at some point and they will allow personal libaries. About "stages" I'm not sure I follow - the "algos" are just plain python code so it's up to you how you want to structure your code. Python is fortunately quite far from commodore 64 Basic which I also happen to rememeber.. with all of it's gotos, pokes and peeks.. (sidenote: I'm not sure if you have ever created your own framework to trade with IB with their api or fix, if you have then you should know how big improvement something like quantopian is.. especially when their costs are basically zero)

spitfire 10y ago
What I mean by stages are independent pieces of code that receive information from higher or lower levels and make decisions based on them. each of these stages will also have their own monitoring in place - what you monitor at the risk stage is totally different from what you monitor at the EMS/OMS stage. So say you have 10 trading algorithms, they'd all send their buy/sell orders on to money management stage (an independent piece of code) which might size the order somehow. Then, if the order passes money management it goes in to risk, where the risk management can OK it, or nix it altogether. Having passed that, your order might go on to an allocation manager - which is now allocating resources between the 6 surviving algorithms. Allocation management will weight resources according to however you see fit - maybe Black-Litterman, and pass things along to execution/order management. EMS/OMS is basically what it sounds like. You say "Buy 100 shares of AAPL", an OMS will go out and make sure they're filled. EMS does the same but tries to make sure it fills them at a good price. None of these things exist, or are reasonably possible in Quantopian in its current state. Personally, I wouldn't trust a dollar to it. Yes, I've built my own trading platform on IB. I have the scar tissue, to prove it. NB: If Quantopian implemented this - even in a fairly clunky, fixed function way I'd consider using them in a heartbeat. Then, my only complaints would be in quality rather than kind.
- mikkom 10y ago
  > None of these things exist, or are reasonably possible in Quantopian in its current state. Personally, I wouldn't trust a dollar to it. My current Q "algo" or whatever we call it (it's a ensemble of multiple "algos") actually has almost every layer you describe (although not using the same methods you describe) and some extra layers you don't describe so it's quite strange for me to read how hard or impossible creating something like what I already have in place is. As I said it's just normal code and python is fortunately quite clean language.
- spitfire 10y ago
  > My current Q "algo" or whatever we call it (it's a ensemble of multiple "algos") actually has almost every layer you describe (although not using the same methods you describe) and some extra layers you don't describe so it's quite strange for me to read how hard or impossible creating something like what I already have in place is. HN won't let me respond directly to this comment. This approach works fine in the small, but as you grow, do research and try new things out it becomes an unmanageable mess. Same reason we have modularity in software development - to separate differing concerns.
  - mikkom 10y ago
    > This approach works fine in the small, but as you grow, do research and try new things out it becomes an unmanageable mess I have quite a long history in creating complex systems so I think my code is quite clean and easy to work with (I have already removed and added methods multiple times). however there are the things that really suck: 1) I'm not able to package the framework to a library 2) copy-paste because of 1. 3) version management hell because of 1.

by mikkom 10y ago

spitfire 10y ago

What I mean by stages are independent pieces of code that receive information from higher or lower levels and make decisions based on them. each of these stages will also have their own monitoring in place - what you monitor at the risk stage is totally different from what you monitor at the EMS/OMS stage. So say you have 10 trading algorithms, they'd all send their buy/sell orders on to money management stage (an independent piece of code) which might size the order somehow. Then, if the order passes money management it goes in to risk, where the risk management can OK it, or nix it altogether. Having passed that, your order might go on to an allocation manager - which is now allocating resources between the 6 surviving algorithms. Allocation management will weight resources according to however you see fit - maybe Black-Litterman, and pass things along to execution/order management. EMS/OMS is basically what it sounds like. You say "Buy 100 shares of AAPL", an OMS will go out and make sure they're filled. EMS does the same but tries to make sure it fills them at a good price. None of these things exist, or are reasonably possible in Quantopian in its current state. Personally, I wouldn't trust a dollar to it. Yes, I've built my own trading platform on IB. I have the scar tissue, to prove it. NB: If Quantopian implemented this - even in a fairly clunky, fixed function way I'd consider using them in a heartbeat. Then, my only complaints would be in quality rather than kind.

mikkom 10y ago
> None of these things exist, or are reasonably possible in Quantopian in its current state. Personally, I wouldn't trust a dollar to it. My current Q "algo" or whatever we call it (it's a ensemble of multiple "algos") actually has almost every layer you describe (although not using the same methods you describe) and some extra layers you don't describe so it's quite strange for me to read how hard or impossible creating something like what I already have in place is. As I said it's just normal code and python is fortunately quite clean language.
spitfire 10y ago
> My current Q "algo" or whatever we call it (it's a ensemble of multiple "algos") actually has almost every layer you describe (although not using the same methods you describe) and some extra layers you don't describe so it's quite strange for me to read how hard or impossible creating something like what I already have in place is. HN won't let me respond directly to this comment. This approach works fine in the small, but as you grow, do research and try new things out it becomes an unmanageable mess. Same reason we have modularity in software development - to separate differing concerns.
- mikkom 10y ago
  > This approach works fine in the small, but as you grow, do research and try new things out it becomes an unmanageable mess I have quite a long history in creating complex systems so I think my code is quite clean and easy to work with (I have already removed and added methods multiple times). however there are the things that really suck: 1) I'm not able to package the framework to a library 2) copy-paste because of 1. 3) version management hell because of 1.