|
PureBytes Links
Trading Reference Links
|
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@xxx> 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/
|