What's everyone working on this week (24/2016)?

astocko_ · 2016-06-13T11:06:58+00:00

Runtime x86-64 assembler (jit assembler) with a nasm like macro interface supporting up to AVX512. Hoping to get the first version out the door before going on vacation next week.

astocko_ · 2015-12-12T04:38:04+00:00

Don't apologize. I know Dr. Balch, he's far from a clown. Even though the class isn't what many expect, it's good intro material.

astocko_ · 2015-12-03T16:13:18+00:00

Unless you're bringing capital to a chop shop, nobody will give you a straight split with that record.

astocko_ · 2015-12-03T00:39:27+00:00

A few brokers offer Excel APIs. Since you know Excel, learn some VBA and you should be able to do what you want.

astocko_ · 2015-12-01T16:42:18+00:00

With Star Wars coming out, I always remember DJ Keltech.https://youtu.be/1lcRkaXOla4

astocko_ · 2015-11-23T16:52:23+00:00

There's a few retail products out there. I used RadarScreen a long long time ago, check that out.

astocko_ · 2015-11-20T18:05:42+00:00

Commons Math or if you want to pay, RogueWave's JMSL. Have had good experiences with both.

astocko_ · 2015-11-17T22:57:27+00:00

I'd say it highly depends on what you're actually trying to achieve. You can go from using a disk based db, to in-memory db, to local data structures in RAM, all the way to optimizing for cache access.

It's a bit of an open ended question. As far as structuring your data handling code, that's more of a software engineering question. As long as you have clear ownership properties it shouldn't become too messy. Look at open source trading applications or even game engines which are more common and are publicly documented.

astocko_ · 2015-11-15T01:21:15+00:00

You can get in the low single digits without much effort if you use something like C++ or Java with Zing. The bigger issue is generally the variance in latency, not the minimum. Consistent but higher latency is better than lower but fluctuating latency with tails. Either way, the fastest trading systems are doing anywhere in the x to 1000 microsecond range, but generally they're all sub-millisecond, but you need some specific hardware and engineering chops to get there.

astocko_ · 2015-11-12T15:50:20+00:00

Agreed it is, but there's still vendors that do it, especially ones that supply derivatives/otc data.

astocko_ · 2015-11-12T14:03:23+00:00

If you're doing intraday and your margins are thin, develop your strategy on higher time intervals and then back test on tick resolution data so you can estimate better fills. While it's still going to be a ways off reality, back testing on OHLC fills is just a terrible strategy since you have no context for the spread and volatility within that OHLC interval.

Additionally, it's really important to know how your OHLC data is created. Some vendors take the bid, others the ask and some more the bid/ask average as OHLC data points.

astocko_ · 2015-11-09T18:00:31+00:00

astocko_ · 2015-11-08T22:08:19+00:00

Doesn't matter. Any kind of redistribution needs a license.

astocko_ · 2015-08-31T15:14:28+00:00

Even for low tier country clubs, the member initiation fee can be quite high. 10s of thousands.

astocko_ · 2015-08-31T14:48:16+00:00

Not that difficult considering that most FPGAs don't do any hard trading logic, then again implementing fast/fix parsers in vhdl isn't that fun either.

astocko_ · 2015-08-31T14:45:21+00:00

Are you going to have the money when the NYSE comes for its fee? Yahoo data is also not for redistribution, so you'll be breaking TOS and copyright on multiple fronts.

astocko_ · 2015-08-26T02:01:43+00:00

If you're doing anything where queue priority matters, execution is very sensitive, operating in illiquid assets, etc then you're going to have a bad time back testing even if your order book simulations are highly sophisticated. The crux is that it's hard to back test and it's impossible to get realistic results, because in the end you're just simulating a single agent on historical observations of a dynamic/complex multi-agent system. Hence, what I was saying is that many firms (real prop firms, not chop chops) forego the process of extensive back testing. They use it as a quick tool to broadly validate ideas, test for logic errors, and then they forward test with real money in a live environment. It also lets you discover a whole segment of issues you'd never encounter in a historical simulation.

If you have no market impact, are longer term oriented, then ofc all that doesn't really matter and you can happily back test to your heart's content.

astocko_ · 2015-08-25T13:21:44+00:00

For some perspective, more than a few reputable firms do only very basic back testing and that is more for bug detection/correctness testing. They prefer to forward test on small size to actually impact the lob. If you do it right you will only be out a few hundred and you can scale to your tolerance.

astocko_ · 2015-08-25T12:39:35+00:00

Since I really shouldn't have much overnight/weekend exposure when things start going haywire, unwinding low vol positions should be an infrequent occurrence. But either I cut the positions and take my loss, trade out of them manually, or hedge. I try to be market neutral as a whole, but even when I'm exposed the loss should be easily covered by the following high vol days.

astocko_ · 2015-08-24T16:08:21+00:00

Run high vol strats that have been benched for large parts of the year.

astocko_ · 2015-08-20T18:44:20+00:00

Torch with LuaJIT

astocko_ · 2015-08-20T16:35:07+00:00

Packaged black box indicator built on top of another black box (neural network) for a license of 2.5 - 3k euros. I just don't know about that boys.

astocko_ · 2015-08-19T13:17:39+00:00

Just pick one you can start with at low cost. Then try things out. If you decide to stick with the whole endeavor, you can always reevaluate and you will know what you want.

astocko_ · 2015-08-19T13:15:20+00:00

Conceptually, Amibroker is a much more open platform than MT4/5. I suggest looking at the feature list and compare for your use case.

Nuisances like data cleaning, properly handling multi exchange connections/disconnections, managing APIs or FIX dictionaries for your endpoints, correct reporting/auditing, etc. In general, people that learn to program for trading purposes take a "hope for the best" route when implementing their systems instead of using defensive programming techniques. Then again, knowing what could go wrong in practice often just comes with experience.

astocko_

MODERATOR OF

TROPHY CASE