Hi,
I've spent all day trying to get my head around certain backtest behaviour in MC. I use i-setplotvalue to output the variables values that indicate where I should be getting filled and they don't always match the chart (only about 50% of the time).
I'm using "fill on touch" backtest assumption.
I think I understand why some show a price difference, as MC will only fill a limit order where there is a tick. So when a two tick skip, MC will improve the fill by a tick.
But it is happening in other situations I can't explain too. Is it something to do with the way MC rounds up/down decimals???? Is there logic in the background that MC uses for converting decimals into prices? Do many decimal places on a variable effect the fill price when backtesting?? Just guessing here.
Would be very appreciative if someone could shed some light on this.
I've attached a screenshot of just one example.....
The image shows:
the entryprice value : "serank[1]" = 1.1065. I get filled at 1.1065 = CORRECT
the exitprice value : is the highest of two values...1) 1.10638 and 2) highest high since fill - 0.00012 = 1.10638.
So why is my target filled at 1.1063 instead of 1.1064?
Is the use of tick charts the reason?
I have many more exampls if needed.
Backtest fills that don't match signal's "i_setplotvalue"
Re: Backtest fills that don't match signal's "i_setplotvalue
Even though I don't know why the above inconsistency occured, I've come up with a fix that solved it.
Before, I was unable to round to 4dp (as one might use with EuroFX) as it caused 0 values for various stop/profit calculations (e.g. 9x0.1=0.9 (=1.0 rounded), whereas 9x0.0(0.1rounded) = 0... creating undesired behaviour).
Therefore I had decided just to use long decimals (e.g. 8dp) BUT this creates the inconsistent behaviour I described.
Solution: use 8dp on figures where 0 values mess up calculations and the correct 4dp on everything else.
Pretty obvious I suppose!
Before, I was unable to round to 4dp (as one might use with EuroFX) as it caused 0 values for various stop/profit calculations (e.g. 9x0.1=0.9 (=1.0 rounded), whereas 9x0.0(0.1rounded) = 0... creating undesired behaviour).
Therefore I had decided just to use long decimals (e.g. 8dp) BUT this creates the inconsistent behaviour I described.
Solution: use 8dp on figures where 0 values mess up calculations and the correct 4dp on everything else.
Pretty obvious I suppose!