we don’t have a strategy more a series of indications as to what the market is telling us. It’s a mix of wet (“brain”), soft ( math) and hardware. One “hint” we use is to calculate the historical volatility over 20 10 and 5 days to see what the trend is and then compare it with the implied vol to see if there’s anything interesting. Simple but effective. We also can examine the trend up or down. Sometime that pops up something interesting and we form a strategy around that.
We tend to use DataFramesMeta.jl ( all hail @bkamins ) for the math as it’s a delight to use and by reading his blog and reading his book we can get a lot done.
We aren’t skilled in julia ( we use c, c++, python and others) but we’ll try to help out if we can.
excellent but please remember it’s just a suggestion. Our “system” is an trading augmentation tool. It’s function is to just give a little reality to an ongoing discussion that goes beyond a restatement of existing indicators. It’s interesting to know what the VIX is at and from it get the 1sd on the SPX but who has a guess as to the COMBINATION of factors that got the VIX to where it is? what other instruments are effecting it and how is that “guess” ratified. It’s not just some variant on the VIX calc it’s Dr Lo’s adaptive market hypothesis.
remember that it’s ONLY a suggestion. We only mentioned it to show how we use this information at a basic level. Sometimes it’s helpful to have industry tried and tested approach.
Another quick question regarding this nice package: If you would like a more complex strategy than a simple Indicator like SMA. Say we want to train a Regression model at every time step and use this regression model to predict the movement of the asset into the future and trade based on the outcome of that model. Is this something that could be done as well? I’m still struggling a little to grasp the ECS paradigm and how that would be influenced by this.
Yes! Actually the ecs paradigm is much more suited for this type of task rather than “reactive” style updates with the new_entities iterator.
It depends a bit on the specifics, but in essence the data is stored in Components, think of them as vectors.
for d in asset_ledger[Open] would give you from start to finish each actual Open data, which “should” be in the order of bars flowing in.
If you’d want to know explicitely the time of each of those values you can do for e in @entities_in(asset_ledger, TimeStamp && Open) which returns the Entities (think of them as indices into the Components that store data, that have both TimeStamp and Open data assigned to them. e[Open] gives you the Open data and similar for e[TimeStamp]. asset_ledger[Close][e] would give you the Close data for e or an error if it doesn’t have that data.
When regressing multiple assets, you’d create a strategy, then state to use it on those assets (see documentation for more info), then inside the update function of the strategy you’d do
for (e1, e2) in zip(@entities_in(asset_ledgers[1], Open && TimeStamp), @entities_in(asset_ledgers[2], Open&& TimeStamp)) and regress on all the data each time new data becomes available (that’s when update is called on the strategies).
A way to conceptualize ECS is that it’s essentially identical to having a sparse table with Entities as rows, and Components as columns. With @entities_in the Systems can iterate over all the rows that have entries for a given set of columns. i’ve actually been thinking to make a formal Tables interface but haven’t got the time to do it yet :p.
@louisponet - Suppose I already have a lot of historical OHLCV data on disk. If I could load that into a DataFrame or TimeArray, is there any way to make HistoricalBroker make use of that? Would a new broker type need to be created to facilitate something like this?
