Overlapping buy/sell orders

[djmuk]

I will look into it, but when I get a quick reversal (eg from up to down and back to up so gekko places a sell followed by a buy on the next candle) and the original order is not completed gekko seems to 'forget' about the original order and only track the new one - I then have to go in and manually cancel the orphaned order. Using 1 minute candles probably doesn't help!

I think it should cancel the original rather keep tracking it and attempting to re-price it and fill it.

[djmuk]

Think I have a fix - testing it (reset this.order =0 on completion or cancel/replace, check in noteorder if this.order<>0 then cancel it)

[askmike]

yes that solution would work, the current setup is not really architected for such fast actions. Are you seeing good results on the 1min timescale?

[djmuk]

as I am on cexio I can say it is saving me from some of the wilder swings but as the market is mainly trading within about a 1% window it is difficult to be sure. I think it is generally going in the right direction. I have made several 'improvements' which I want to separate out into specific commits, but need to do the 'proper' job first!

• Buy at bid / sell at ask (offset by small amount) rather than current sell at bid, buy at ask.
• A couple of different pricing values for candles (EMA on VWAP and EMA on trade price)
• There is a glitch on using persistence when the market reverses quickly (persistence count isn't reset)
• Possibly combine the majority of MACD & PPO methods (decision making etc) into one block of code with the PPO.JS and MACD.JS just making appropriate calls.
• Logging - suggest we put in the spec logging levels and put log : N in config section for each actor/method/etc, eg
• N=0 NO logging
• N=1 Log only actions (Buy/sell complete, method trigger reached)
• N=2 log verbose - for each candle log OHLCV etc, method final calculation values)
• N=3 debug/detailed - probably similar to current debug - steps in each process. By setting this per section users can look at detailed logging for methods (to tune them) without the noise of other areas having detailed logging on.

[askmike]

Looking forward to the pull.

• Buy at bid / sell at ask (offset by small amount) rather than current sell at bid, buy at ask.
• A couple of different pricing values for candles (EMA on VWAP and EMA on trade price)

Please make those configurable!

I like the logging idea a lot :) If you send a pull I'll gladly put it in.

[djmuk]

OK - I need to work out how to isolate those bits from the other tweaks I have made! I might end up creating a new repo and making the changes there.

At present all the candle values are single letters (OHLCVP) - are you keen to keep to that pattern for any new stored values or can we use more letters? I am thinking of creating extra price indicators as I mentioned above. EMA of VWAP (SO EMA on pricexV

[askmike]

I am thinking of creating extra price indicators as I mentioned above. EMA of VWAP (SO EMA on pricexV

So the P in OHLCVP is the VWAP already, I calculate it myself for all 1min candles and upscale to bigger candles accordingly.

Do you mean you also want the store some indicator result like EMA result in the database? Or do you mean you need the VWAP? If the latter you can do that already (access it by candle.p). If the first I don't fully understand what you are trying to do and why you want it as part of the candle?

[djmuk]

MIke I am proposing 2 extra price indicators, for the following reasons:

• Close price is purely a random sample of the trading price - it may have been significant when markets closed at the end of the day and folks would try and close out their trades but with continuous trading a close price is purely a random sample price.
• VAWP is better in that it reflects both the average price across the candle interval and also the volume traded at those prices. However it is susceptible (IMHO!) to being spiked by large 'market' trades that both spike the price and have a significant volume. Also all trades are given equal significance when it might be argued that trades later in the candle are of more significance.
• 'Average' (IE Mean) price across the candle might be an alternative but loses temporal (time) information - trades are evenly weighted whenever they occurred.

I am suggesting the following (which need to be calculated directly from trade data so need to be stored in the candle store) - P here is the price of each individual trade not the VWAP.

• EVWAP - EMA weighted Volume Weighted Average - This is similar to VWAP but gives greater weight to the later trades. This would be calculated by taking an EMA Across P * V (Epv) and dividing by an EMA across V (Ev) .= Epv/Ev. Also requires storing Ev,,,
• EMAP - EMA weighted price - This takes into account all the trades (price only) across the candle period but gives greater significance to the later trades. This would be an EMA across P across the candle.

For consolidating candles into n x 1m candles these would be combined as

• EVWAP - Reverse the division - so take EVWAP * Ev for each candle and EMA them alongside the Ev vales and then recalculate the Epv/Ev value for the consolidated candle.
• EMAP P - take an EMA of the EMAP values across the N candles.

It is simple to make an EMA across N Values of X (X1 .. XN below where XN is the last value) even if you don't know N at the start: EMA = (1 x X1 = 2 x X2 + 3x X3...+ N x XN ) / (N * (N-1)/2)

[askmike]

This should be fixed in the new portfoliomanager!