|
PureBytes Links
Trading Reference Links
|
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <amibroker@xxxx>
wrote:
>
> Hello,
>
> > My hypothesis is that the root of the stop problem is that ApplyStops
> > itself uses current bar High (when in Long position) which can lead to
> > situations where that is indeed future information (e.g., Low of day
> > triggered the stop but the Low happened hours before the High of the
> > day happened and thus it should not have been triggered).
>
> This topic appears here over and over again, so once again I explain:
> usign EOD data you have NO WAY to know whenever High occurred earlier
> than Low or vice versa.
>
Wasn't aware it was a topic discussed over and over. I saw it
referenced once before as I pointed out. I do believe however that it
is a problem despite what you state below.
> If you use EOD data you need to make some assumption. And AmiBroker
takes
> WORST case assumption (i.e. if low is below trail stop it exits the
trade).
> You end up with less profit but it safer to generate backtest
showing smaller
> profits than assuming "good luck".
>
Why not use prior bar's High instead of relying on assumptions of
using current bar High? Although you make an assumption (that seems
not risky), it still leads to postdictive errors and causes at times
to exit too early which can lead to both more profits AND less profits
depending on the situation.
For example, there is a differential of profit > 20% using your
ApplyStop method on IBM trade on 3/13/00 exiting prematurely @ 104.00
instead of letting profits run to 3/28/00 @ 123.25. Having ExitAtStop
reference previous High-Low instead of current High-Low would allow
you to make no assumptions and be more accurate in my opinion. I
still don't see why ApplyStop cannot reference prior bar H-L instead
of current bar H-L??
And an example where you exit prematurely that leads to more profit
than you should have via GOOG sell on 1/19/2005 @ 200.30 instead of
1/20/2005 which gapped down and really should have sold for 192.5.
> This is safer than assuming that low happens before high (very risky)
>
I think its risky to assume anything in the current bar even if you do
try and limit this risk. In my opinion, why not assume at all and be
sure? Why not eliminate any risk altogether and reference the prior
bar H/L as basis of the trail?
How about a compromise and let us users who use EOD data and
ApplyStops to have the option in ApplyStop (let's call it StopBasis)
and allow it to be either 0 (default value that is current behavior)
or 1 (use prior bar's High-Low as basis of determining where trail is
subtracted/added from instead of current bar's High-Low; and let it be
Null when current bar is an entry bar)?
For example:
ApplyStop(stopTypeTrailing, stopModePoint, trailLongPoint, exitAtStop,
volatile=False, reEntryDelay=1, stopBasis=1);
> Also your code uses BarsSince(Buy) to calculate High since entry of
long trade
> which is incorrect if Buy formula generates repeated signals.
>
I don't use BarsSince(Buy) to calculate High. I use it simply as
device to determine trail period for plotting purposes. Are you
saying that my two lines below that simulate the ApplyStop trail line
is incorrect? It seems accurate to me and I haven't seen a case yet
where its wrong when using it to visualize your ApplyStops in this
code. If so, can you point out the precise symbol and date where its
inaccurate?
Please note, I do execute a Equity(2) in my code which should
eliminate repeated signals that you mention and furthermore, I
recalculate these trail values after executing the Equity(2) function
to deal with the delays. The plot code below does indeed seem to show
the proper values:
Plot(stopLongTrail, "TrailL", colorRed, styleStaircase);
Plot(stopShortTrail, "TrailS", colorBrown, styleStaircase);
Please do try my code and see for yourself. I don't think there is an
error with these plots that show the ApplyStop trail. I've been
working on this code for awhile and think it is good.
Finally, what about problem # 2 that I pointed out. You did not
address this (quoted again below):
"Also, when backtesting with AA, you'll notice problem with handling
some gaps properly. It will not respect open gaps down and give them
precedence for trailing stops all the time. It seems to be a bug with
partial gaps only instead of full gaps.
Examples of incorrect stop values due to partial gaps with
ActivateStopsImmediately
is set to True:
* EBAY 1/21/1999 sold @ 8.37 but should have sold 1/21/1999 @ 8.21
(Open gap)"
Regards,
JD
------------------------ Yahoo! Groups Sponsor --------------------~-->
Try Online Currency Trading with GFT. Free 50K Demo. Trade
24 Hours. Commission-Free.
http://us.click.yahoo.com/RvFikB/9M2KAA/U1CZAA/GHeqlB/TM
--------------------------------------------------------------------~->
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|