WLJenkins
commented
11 years ago Here's what I have so far - it's not pretty as my first language is not Java. Please take a look and speculate as to the effectiveness of what I'm trying to accomplish.
What I'm attempting to do is to scale UP the indicator exponents when MtGox responds in under a target polling interval. Conversely, I want to scale DOWN the indicator exponents when MtGox responds much more slowly than the target polling interval.
I'm familiar with how EMA, SMA, MACD short, long, signal lines, negative/posivite are calculated, but from a very different approach than what is used in AidoATP. So, by reviewing the code in Observer - it is not quite clear if the formulae being used result in the same type of waveforms as the examples I've built with my own tools. And, ultimately, being able to reproduce behavior in my own tools with the behavior of AidoATP indicators is the ideal state. What I may end up doing is enabling log debug mode, stream it to a file and then parse it for waveforms and compare that to my own tools.
------ tickerSize = ticker.size(); lagSuspendTrading = false; if(tickerSize > shortMACDSize){ currentTickTimeStamp = tick.getTimestamp(); shortAvgTickTimeStamp = ticker.get((tickerSize - 1) - shortMACDSize).getTimestamp(); lagScaleFactor = (double) (TimeUnit.MILLISECONDS.convert((shortMACDSize * targetPollingInterval),TimeUnit.SECONDS)) / (double) (currentTickTimeStamp.getTime() - shortAvgTickTimeStamp.getTime()); }else if (tickerSize > 1){ currentTickTimeStamp = tick.getTimestamp(); shortAvgTickTimeStamp = ticker.get(tickerSize - 2).getTimestamp(); lagScaleFactor = (double) TimeUnit.MILLISECONDS.convert(targetPollingInterval,TimeUnit.SECONDS) / (double) (currentTickTimeStamp.getTime() - shortAvgTickTimeStamp.getTime()); }else{ lagScaleFactor = Double.valueOf(1); } // // // lag-poll interval scaled indicator exponents // expShortEMA = (double) 2 / ( (double) (shortMASize * lagScaleFactor) + 1); expShortMACD = (double) 2 / ( (double) (shortMACDSize * lagScaleFactor) + 1); expLongMACD = (double) 2 / ( (double) (longMACDSize * lagScaleFactor) + 1); expSigLineMACD = (double) 2 / ( (double) (sigLineMACDSize * lagScaleFactor) + 1); //
Following is the console output integrated lagPollingFactor, the scaling and the application's response to varying degrees of lag.
2013-05-19 06:58:17,856 WARNING: MtGox - polling lead/lag exceeds 20%. Indicators are being adjusted to compensate. 2013-05-19 06:58:17,856 MtGox USD - Ticker size: 104 LAG/LEAD: 73.0% less responsive 50 sec polling interval. 2013-05-19 06:58:17,857 MtGox USD - Trend observer does not currently have enough data to determine trend. 2013-05-19 06:58:17,858 MtGox High USD :- Last: USD 123.00000 | Bid: USD 122.87000 | Ask: USD 123.00000 | Volume: 11556 | Currency: BTC | TimeStamp: Sun May 19 05:12:58 EDT 20 2013-05-19 06:58:17,859 MtGox Low USD :- Last: USD 122.59591 | Bid: USD 122.59591 | Ask: USD 122.64998 | Volume: 11115 | Currency: BTC | TimeStamp: Sun May 19 06:36:22 EDT 201 2013-05-19 06:58:17,860 MtGox Current USD :- Last: USD 122.66552 | Bid: USD 122.66549 | Ask: USD 122.66550 | Volume: 11145 | Currency: BTC | TimeStamp: Sun May 19 06:58:11 EDT
I thought of a request that might be more useful. Exchange lag-based polling interval scaling.
If one has a trading tactic that assumes certain velocity and all of the sudden effective polling interval changes from an average of 30 seconds to 1.5 minutes, one could argue that the resulting indicators could be skewed to an extent that undermines the intent and effectiveness of the rules and ticker parameters defined.
So, I'd propose that the Polling Interval parameter be scaled in real time based on ticker lag. When MtGox is low lag, no scale, when lag, scale the polling interval inversely.
Just a thought and likely something I will attempt to do on my own.