|
PureBytes Links
Trading Reference Links
|
Correction on the comment:
"To counter that, you could just add a flag that gets set when you
find a PositionScore equal to the minimum score and only allow the
symbol to be accepted the first time that happens, any other symbols
with the same PositionScore would be set to PositionSize of 0 and
filtered out."
That could falsely filter valid signals when you had enough slots to
fill and multiple symbols shared a PositionScore (e.g. if had 4 slots
to fill in my earlier example, would not want to filter D just
because it shared PositionScore with C).
Hopefully you get the point and can come up with a suitable check.
You might set a counter to the number of open slots and decrement it
at each valid signal processed. Your filtering logic would then zero
out the PositionSize if less than the minimum PositionScore OR the
counter was already at zero (to handle duplicate PositionScores).
That makes the backtester code a bit more complicated, but the
advantage remains; You only have to get it right once, then it can be
reused for other conditional entry strategies.
Mike
--- In amibroker@xxxxxxxxxxxxxxx, "Mike" <sfclimbers@xxx> wrote:
>
> Matt,
>
> Tomasz's final reply looked like it would address the issue, but
> involved changing your entry logic, which I was trying to avoid
(i.e.
> do not filter Buy based on whether limit order met, handling it
> instead in your backtester logic) and would have to be reworked for
> each conditional strategy (i.e. would have to alter backtester
logic
> to address different conditional entries) which I was also trying
to
> avoid. However, the simplicity of his solution should not be
> undervalued.
>
> That being said, I personally have been sticking with my own
> solution :)
>
> Without actually seeing your code, it is difficult to comment. But,
a
> couple of things to check would be:
>
> 1. Are you obeying the assumption of assigning PositionScore as
only
> zero (setup not met) or a positive value?
> e.g. (where ... results in a positive value)
>
> PositionScore = IIF(Ref(setup, -1), ..., 0);
>
> 2. Are you assigning PositionScore based on the *previous* day's
> values? Your exploration will show signals for the current day, the
> top X of which you will place limit orders for the next day.
> Therefore, your script must assign a PositionScore using
yesterday's
> information when today's price action meets your limit entry
criteria.
> e.g. (notice Ref(setup), -1)
>
> PositionScore = IIF(Ref(setup, -1), ..., 0);
>
> 3. When there are no slots available (minPos == 0), are you setting
> the posScores array to some large number greater than any
anticipated
> PositionScore?
> e.g. (notice 9999)
>
> posScores = IIF(minPos, Foreign("~Position" + minPos, "X", 0),
9999);
>
> 4. Is your custom backtester code filtering correctly (i.e.
correctly
> comparing the PositionScore of the signal against the *minimum*
> permitted ~PositionX). You can add a _TRACE statement to print out
the
> minPos value being used in the posScores assignment above and
compare
> it against the number of slots you are trying to fill.
>
> Also, I do notice a limitation in the code that I posted. In the
case
> where multiple symbols meet the setup criteria, and have the same
> PositionScore for a given bar, and at least one of them is in the
top
> X positions; *all* of those symbols will be accepted by the
backtester
> for addition to your portfolio (subject to max number of positions
and
> available funds) even if only a subset of them qualified as the top
X
> positions.
>
> e.g.
>
> Assuming a 5 slot strategy and already holding 2 positions, you
would
> in reality only place orders on the top 3 candidates (5 - 2 = 3).
>
> However, if multiple candidates shared a PositionScore with one of
the
> top candidates, they too would be accepted by the backtester since
we
> only zero out PositionSize for those that were *less* than the last
> acceptable position (i.e. less than the 3rd PositionScore in this
> example).
>
> So, given an exploration like the following
>
> Symbol:PositionScore
> --------------------
> A : 75
> B : 60
> C : 48
> D : 48
> E : 48
> F : 23
> G : 19
>
> The code would correctly filter out F and G as having a
PositionScore
> *less* than that of the top 3 candidates (i.e. less than 48). But,
D
> and E would still be allowed to sneak into your portfolio since
their
> PositionScores are *equal* to the lowest permitted and thus would
not
> be filtered.
>
> In my particular case, the PositionScore is the result of a
function
> based on historical volatility and has not (so far) resulted in
> duplicate values between candidates, so it has been a non issue.
>
> However, if your PositionScore logic results in many shared values,
I
> could see how unexpected entries would be sneaking in to your
> portfolio. To counter that, you could just add a flag that gets set
> when you find a PositionScore equal to the minimum score and only
> allow the symbol to be accepted the first time that happens, any
other
> symbols with the same PositionScore would be set to PositionSize of
0
> and filtered out.
>
> The catch being that when placing your top X orders, you would have
to
> use the same selection criteria to break the tie as would be the
order
> in which AmiBroker processed the signals. I suspect that they will
be
> processed in alphabetical order, but you'll need to verify that.
>
> Hope that helps.
>
> --- In amibroker@xxxxxxxxxxxxxxx, "mertema" <mertema@> wrote:
> >
> > Mike, I came across your code recently and appreciate the effort
to
> try
> > to solve the "limit order" problem that Tomasz et al. do not seem
to
> > understand.
> >
> > I've implemented your code and have begun to test with my model
and
> I'm
> > struggling to reconcile the results from explorations to the
> backtest
> > results - in particular position scores outside of the top 10
during
> an
> > exploration that show up in the backtest.
> >
> > Any insight would be greatly appreciated.
> >
> > Thanks, Matt
> >
>
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 NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
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/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> 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/
|