garyfritz wrote:Interesting. Thanks for that insight, Sq.
So tell me, does an EA use exactly the same insane execution model as indicators? I.e. re-executing the code for recent bars, etc? That behavior causes repainting in indicators but I would think it would be impossible in EAs. You don't get to go back and change your mind about the trade you placed 3 bars ago. If EAs *don't* use that logic, then how hard is it to move indicator code into an EA?
No, EAs do not use that logic.
When a tick comes in, start() is called, just like indicators, but EAs do not have access to those indicator data "buffers".
EAs can invoke indicators with iCustom();
iCustom() will :
- load the indicator,
- run its init()
- run its start() ONCE with a "certain" amount of available history data, so it can create its "buffers",
- when start() returns, iCustom() returns with the element of the "buffer" specified by the last 2 arguments passed to iCustom().
This process is performed at each call to iCustom().
This is why fixing the EMA computation does not matter for an EA that would use iCustom(), as the "indicator" will rebuild all of its buffers at each call.
What makes moving indicator code into an EA difficult (sometimes) is that the EA needs to simulate what the indicator does with past candles. It needs to maintain the equivalent of the "Buffers" if past values of the Buffers are needed to produce the latest indicator value.
In order to calculate an EMA in an EA, you need to recalculate all past values of the EMA in order to get the latest EMA value.
Not a big deal in the case of a moving average or similar, but it can get very tricky when the indicator is complex.
garyfritz wrote:
BTW it would be possible to backtest this, with a bit of effort. We could modify the indicator to dump all its strength values to a file, then write the EA to pull its values from the file instead of the indicator. (Can an EA trade multiple pairs in a backtest?) Might be a pain but it would be nice to be able to see how this would actually work. If that's not possible, I might try dumping pair data to a spreadsheet and hack together a backtest by hand. That definitely WOULD be a pain.
Agreed!
This is a possible solution.
It requires a 2-steps backtest:
-1- create the currency-strength-values file with a specific indicator (an option added to your indicator will do the trick)
-2- run the backtest where the EA will load the file and retrieve the record corresponding to the timestamp of the "current bar" being handled by the EA in its start() function.
IsTesting() can be used to decide if the EA should call iCustom() ("real-time" mode), or read data from the strength file (backtesting).
The pre-processed strength file could be a CSV where each "line" has a timestamp and the strength value.
Easy to implement.
garyfritz wrote:
I think data is going to be a bigger problem. This indicator pulls data from 8 pairs. If any of those pairs have bogus data, it throws off the calculation. E.g. PFG has bad data in NZDUSD so the NZD index gets screwed up. It actually screws up everything, but it's strongest in the NZD index.
This is a very good point.
And this is again a big bloop in Empty4...
When you copy pair price series with ArrayCopySeries(), it simply copies the price series into that array.
But if bars are missing in the pair original series, then the copied series will also have the same missing bars.
What is even worth is that, just like Close[] or High[] or any other price series, consecutive elements of the series do NOT necessarily have a constant time difference...
In other words, in the H1 Close[] series, Close[9] may be more than 1 hour away from Close[8].
This is what happens on week-ends for instance.
But it also happens when history data is missing...
In your indicator, you are using ArrayCopySeries() to copy all pairs into arrays, and you are then ASSUMING that NzdUsd has the same TIMESTAMP as EurUsd.
But this is WRONG, thanks to Empty4 designers!
This is what is screwing your indexes currently.
You should rather use iClose(pair,0,iTime(NULL,0,i)) to be sure to read the correct candle of each pair for the given "shift".
If that value is 0, then it means that candle does not "exist" in the pair, and you should exclude this pair for the index calculation of that candle.
That will fix the bogus pair data.
garyfritz wrote:
There's also the question of how to get enough good data to do any decent testing. I don't understand Empty4's model for how much data it charts, how much is available to an EA, etc. Somebody posted a script a while back to populate data in all pairs, but I can't find it. Does anyone have a pointer to that?
is that it ?
http://www.stevehopwoodforex.com/phpBB3 ... 8437#p8437
sq |
). But since I haven't written any EAs, I haven't discovered if they use the same braindead stupid benighted idiotic f'ing DUMB execution model as indicators. I don't know if fixing the indi will make the code work in an EA.
