View Full Version : Initial Stop Using Wrong Bar's Data
mcdirt
27th September 2003, 08:56 AM
Using TS v3.2.0 Build 665, I have encoutered what I consider to be a bug in the way the Initial Stop function is used for calculating position sizing.
I use %risk position sizing models and use a moving average to set the intial stop. I use the 'EnableDelayOfEntryByOneBar' function to enter the next bar after the entry criteria are met, at the Open price.
Examining the Trade Log data, I can see that Tradesim is using the moving average of the entry bar in its position sizing calcualtions, not the signal bar. This is contrary to what I would have expected and does not mimic the way a trader would set position sizes prior to entering a trade.
I trade weekly charts so, when backtesting, TradeSim is using the moving average that would not be known until the Close of the Friday after the actual entry. This makes a difference in my $risk figure and therefore the position sizes and can result in large differences in the resulting trade profits.
To me, this is incorrect.
David Samborsky
27th September 2003, 11:46 AM
TradeSim will use the stop calculated on the day of entry even if it is delayed.
To use the previous bars stop use the ref( ,-1) in your expression for the InitialStop. Note a similar thing is done for a trailing stop where we purposely use the previous bars value in the trailing stop expression because the ATR is dependent on the closing, high and low values and these are not known until the finish of the days trading.
ExitLong:=(L <= ref(BandLong,-1));
The reason why the stop is not delayed by default is because sometimes you may want to use a stop which is dependent on the actual Price at Entry. It depends on how you construct the stop as to whether or not you should delay it. For example the following does not need to be delayed since it is not dependent on C, H or L.
EntryPrice=Open;
IntitialStop:=0.9*EntryPrice;
mcdirt
28th September 2003, 03:52 AM
David, as you say - it's easy enough to code to use the previous week, if you are aware of the fact the program works in this manner. I was not and wonder if others still do not ... I do not recall reading this in the documentation (though it may be there).
Is it true to say, then, that any reference to OHLC in entry trigger uses the signal bar and if you enable the delay, then any reference to OHLC uses the data from the entry bar (one bar later)?
So if I refer to Open in the Trigger formula, enable the delay and then refer to Open in the Initial Stop formula, they use two different values for the Open!
David Samborsky
28th September 2003, 12:47 PM
Yes the manual needs to clarify it a bit more so there is no confusion. I will look at expanding this section of the manual in the future. It could be a manual in it's own right.
To clarify further:-
Is it true to say, then, that any reference to OHLC in entry trigger uses the signal bar and if you enable the delay, then any reference to OHLC uses the data from the entry bar (one bar later)?
So if I refer to Open in the Trigger formula, enable the delay and then refer to Open in the Initial Stop formula, they use two different values for the Open!
What you have said is essentially correct. The delay of one bar does not hold over the price from the previous bar when Entry and Exit prices are concerned. It's only the entry and or exit triggers that get delayed and hence the prices from which they are made up get held over from the previous bar.
jacche
13th November 2003, 01:40 AM
David,
Finally i think this addresses my concerns for the last 2 weeks about bugs (reverted to MS7.2) and data integrity. i believe i have also exprienced a similar situation with the use of EnableDelayOfEntryByOneBar. In my case what i am trying to do is set the Initial Stop to be lowest value in last 3 days prior to (excluding) trigger day and I kept getting stops which included the trigger day itself.
Hence to achieve my required outcome would mean using Ref(LLV(L,3),-2)
rather than what i have below
e.g.
EntryTrigger = {entry condition}
InitialStop = L<Ref(LLV(L,3),-1) {prior to calling RecordTrades}
pls confirm that i have understood that is how tradesim treats it, sorry if this is a reconfirmation but i am new to tradesim and metastock
pls advise, many thanks
jack
jacche
13th November 2003, 02:20 AM
David,
I am a bit confused by your last statement so if i understand correctly then what you are saying is that the sequence of the assignments (in my case, trigger, initial stop followed by initialize and enable delay) is irrelevant and that once you enable delay of entry by one bar then any reference to OHLC outside of the Entry or Exit Triggers automatically refer to the Entry(delayed) day's OHLC rather than the signal day ?
Is that correct ?
Many thanks
jack
David Samborsky
13th November 2003, 06:05 AM
Delaying the EntryTrigger should be looked at from the point of view of entry into the market tommorrow because todays exit trigger was asserted. However when referencing prices using EntryPrice, ExitPrice and InitialStop then everything is relative to the delayed point (tommorrow) and not the previous bar (today) which caused the trigger in the first place even though the previous bars prices were used in your formulas to generate your triggers.
Normally if you entered today and wanted to use your stop for the previous three days you would use
InitialStop:=L<Ref(LLV(L,3),-1) ;
but if you delay entry by one bar and enter tommorrow and wanted to use the same three days in calculating your stop then you should use
InitialStop:=L<Ref(LLV(L,3),-2) ;
Note that when using delays that the trigger is carried forward from the current bar but any reference to prices are referenced from the next bar.
Hope I haven't confused you!
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.