i'm more on the road to studying things statistically in options/futures/ and related underlyings.. my thoughts are generally towards that direction.. of course i'm still learning ..and i'm glad i enjoy it.. or it would be quite the grind..i'm sold on SSD's though.. i raid zeroed my first two.. haha thought about a hardware raid controller at times.. i hang out with a couple guys that are in the clustering business, network, and as well the linux world.. no on seems to be as confident about anything as they are with their preferred linux distro.. i'm not really to the point where i can really leverage the technology with the right questions, and i don't have the capacity to write code at all in lower level languages.. hopefully before you know it i will ..
How to build an automated system
- Thread starter hft_boy
- Start date
i'm more on the road to studying things statistically in options/futures/ and related underlyings.. my thoughts are generally towards that direction.. of course i'm still learning ..and i'm glad i enjoy it.. or it would be quite the grind..i'm sold on SSD's though.. i raid zeroed my first two.. haha thought about a hardware raid controller at times.. i hang out with a couple guys that are in the clustering business, network, and as well the linux world.. no on seems to be as confident about anything as they are with their preferred linux distro.. i'm not really to the point where i can really leverage the technology with the right questions, and i don't have the capacity to write code at all in lower level languages.. hopefully before you know it i will ..
was entertaining listening to the ramblings of a crazy man
Quote from hft_boy:
Hey,
I figure I'll spend half an hour to an hour a week writing about various aspects of building the infrastructure behind a trading system. Why? I guess I'm just kind of bored, and there seems to be precious little written on by people who know what they are doing. And I feel the need to thrust my views on the world.
I guess my first post will be about my general philosophy/approach towards programming.
First, don't optimize until it is needed. Focus on the logic of the code first, get it right, get it simple, make it easy to understand. Then, when optimizing, know your patterns of usage, and use the correct hardware/language/data structure for the job. It seems like every other day somebody recommends an SSD for accessing files faster. Well, for files which are read sequentially (e.g. data files), there is basically no difference between spinny drives and NAND drives because the bottleneck is in SATA transfer speeds, not seek time! Yeah there is like a millisecond difference in seeking to the start of the file but unless you are hammering the drive with a thousand requests a second, there is not going to be a noticeable difference.
Don't use too much abstraction, and don't use too little abstraction. Einstein is attributed with saying that "everything should be as simple as it can be, but not simpler." I tend to agree. Don't make too many classes. Don't make too few. (Don't use C++, herp derp). It comes down to patterns of usage and not prematurely optimizing. There is no point in abstracting away five lines of code. More to the point, it can actually be dangerous -- too much abstraction kills the ability to know what can be assumed about the code, which is a serious problem come testing time. This brings me to my next agenda.
Write code which is easy to test for correctness. It's really hard to get this right, and even experienced programmers mess up all the time. What I try to do is write code in such a way that there are 'logical bottlenecks', so that the number of assumptions that have to be made about each section is limited and you can assert the crap out of it, so that when it breaks it isn't subtle. Test pre-conditions, post-conditions and invariants. Put as many of these tests as possible into compile time (e.g. const-correctness).
This problem of actually knowing what various pieces of code are doing is one of the reasons I don't like using really high level abstractions/languages and try to keep external library usage to a minimum -- unless the documentation is very good, and you read it carefully, you won't know what assumptions you can make about the code (e.g. did you know that java.lang.Math.round is different from C's "math.h" round? #omgmymindwasblown). Even if you read the documentation, you should just go and read the source code anyways to double check that it actually does what it claims to do. IMHO not being aware of what assumptions can be made about code which executes behind the scenes especially as it pertains to the outcome of the code is seriously sloppy work and is not acceptable for production systems.
Well, anyways, that's about it for the week. Hope that this was entertaining or that maybe you even learned something from it!
I for one appreciate the effort hft_boy put in, I find it ridiculous to ask for code or to discount his efforts in any way.
Can we all stay real? This is about how to build an automated system not a working strategy.
The problem with this website is that it does not only attract those of lower intellect and little to no education like flies are attracted to sh...., but that it draws the lazy to it like a magnet. The few gems far in between are then even ripped off their arms and legs in exchange for reaching out a helping hand.
Can we all stay real? This is about how to build an automated system not a working strategy.
The problem with this website is that it does not only attract those of lower intellect and little to no education like flies are attracted to sh...., but that it draws the lazy to it like a magnet. The few gems far in between are then even ripped off their arms and legs in exchange for reaching out a helping hand.
I've taken a lot from et but I try to contribute as much as I can... there is always someone that knows less..... the point is you think people that are idiots get more then what they deserve on et...... well at least this idiot appreciates it.. you have lost your ground in life if you become unwilling to help ... but respectively there is a big difference between helping giving your edge away...
Jebus I didn't actually expect so many responses.
@clearinghouse: Provider. And don't have access to serious speed although I wish I did
.
@kut2k2: Focus is on fast stuff. But principles apply to lower frequency trading as well.
@hftvol: I stand corrected. I guess on *my machine* that I currently use there is no difference. Also my preferred way is to read single files, with all the data, sequentially. Having one symbol per file also strikes me as complicated but hey whatever works!
@abattia: Don't know about a rule of thumb. Empirically my class file sizes max out around 500-700 lines of code. Here's an example: http://bit.ly/cBkcPE. It's about binary search, which is conceptually simple but ****ing impossible to get right the first time around. As another example which pertains to trading, consider the queue of orders at a certain price point (I use a doubly linked list). One really powerful test is to assert that if tail==head (i.e. there is only one order left) then assert(to_be_deleted==head). It sounds totally stupid, like duh -- but it's basically the one thing that has to be true about the list at that point. And it's saved my implementation multiple times.
@SeventhCereal: Glad you enjoyed it!
@2rosy: Will do. I think this weekend I'll post something about lock free multiprocessing.
@clearinghouse: Provider. And don't have access to serious speed although I wish I did
.@kut2k2: Focus is on fast stuff. But principles apply to lower frequency trading as well.
@hftvol: I stand corrected
. I guess on *my machine* that I currently use there is no difference. Also my preferred way is to read single files, with all the data, sequentially. Having one symbol per file also strikes me as complicated but hey whatever works!@abattia: Don't know about a rule of thumb. Empirically my class file sizes max out around 500-700 lines of code. Here's an example: http://bit.ly/cBkcPE. It's about binary search, which is conceptually simple but ****ing impossible to get right the first time around. As another example which pertains to trading, consider the queue of orders at a certain price point (I use a doubly linked list). One really powerful test is to assert that if tail==head (i.e. there is only one order left) then assert(to_be_deleted==head). It sounds totally stupid, like duh -- but it's basically the one thing that has to be true about the list at that point. And it's saved my implementation multiple times
.@SeventhCereal: Glad you enjoyed it!
@2rosy: Will do. I think this weekend I'll post something about lock free multiprocessing.
Oh, I forgot to answer this. Nothing is *wrong* with C++ per se. It is just hard to write, hard to read, hard to maintain, and generally messy/ugly. Especially -- who the f*** came up with templated code? It kind of makes sense, but is impossible to work with. FWIW my C++ is basically C with some classes for reusable code and the occasional std::vector. Even std::string makes me shudder
. I think it is just std::vector<char>. Like, seriously? Is that really necessary?Quote from hft_boy:
Oh, I forgot to answer this. Nothing is *wrong* with C++ per se. It is just hard to write, hard to read, hard to maintain, and generally messy/ugly. Especially -- who the f*** came up with templated code? It kind of makes sense, but is impossible to work with. FWIW my C++ is basically C with some classes for reusable code and the occasional std::vector. Even std::string makes me shudder
your speakings are out of my realm.. my dome piece does not compute.. no processing capacity existent there yet..
i'm sure alot of code was developed to the ideology of the creater.. and for there particular uses.. you theoretically could write a desktop app with php.. would you..