Mike,
I am not sure where you see any problem. Whenever the margin
is enough to handle the problem or
not depends on your broker and their policies. Some are more
flexible than others.
My systems don't generate that many signals each bar, but if
your system generates so many signals
and you need to place limit orders for way more than your
broker margin account would allow,
you can simulate "reserving" process in custom
backtester,
and it seems that you have already done that.
If you are asking if I have easier method - yes I have. My
code is shorter and is quite simple actually
- I am just checking limit orders inside CB and reduce
available cash for that particular bar
and then re-add it after signals are processed
setup = .... BuyPrice = Ref(Close, -1) * 0.95; //
store limit price unconditionally Buy = Ref(setup, -1); // don't
put price penetration condition here - will be handled in
CB Sell = .... /* */ SetCustomBacktestProc("");
if (Status("action") == actionPortfolio) { bo =
GetBacktesterObject();
bo.PreProcess();
for (bar = 0; bar < BarCount; bar++) {
ReserveCash = 0;
for (sig = bo.GetFirstSignal(bar);
sig;
sig =
bo.GetNextSignal(bar)) {
if (sig.IsEntry() AND
sig.IsLong() )
{
LowPrice =
Foreign( sig.Symbol,
"L" );
if( sig.Price < LowPrice[ bar ] )
{
// trade is NOT entered because limit is not
reached
if( sig.PosSize
> 0 ) PosValue = sig.PosSize;
else PosValue = bo.Equity *
-0.01 * sig.PosSize;
ReserveCash
= ReserveCash + PosValue;
bo.Cash =
bo.Cash - PosValue; // subtract from available
cash
sig.Price = -1; // this
marks the signal to be skipped }
} }
bo.ProcessTradeSignals(bar);
bo.Cash = bo.Cash
+ ReserveCash; //
add the reserved cash back }
bo.PostProcess();
}
Best regards, Tomasz
Janeczko amibroker.com
----- Original Message -----
Sent: Wednesday, September 05, 2007 1:04 AM
Subject: [amibroker] Re: How do I backtest placing a
restricted number of limit orders each night?
> Just a quick correction to
my previous reply. I have received as many > as 60 "setups" in one night,
not all of which result in > AmiBroker "signals" on the next trading day
(due to limit order not > being reached). > > Similarly, I
meant to say that expanding the one position example, > you will hit the
same problem as soon as you have more "setups" than > available
funds. > > Sorry for any confusion. > > --- In
amibroker@xxxxxxxxxxxxxxx, "Mike"
<sfclimbers@xxx> wrote: >> >> Tomasz, >>
>> Thank you for your continued replies. >> >> I am
trading in a REAL account in REAL life with 50% margin. Some >> nights
I get few signals, other nights I get many. I trade over > 7000
>> symbols accross NYSE, NASDAQ, and AMEX. I have had as many as 60
>> signals in one night. Even using all available margin, there are
>> sometimes not enough funds to cover the orders. >>
>> Saying that your strategies do not encounter the problem does not
>> imply that the problem does not exist. >> >> I
gave a simplistic one order example just to illustrate the point. >>
Now that you understand the scenario, expand the example to a 10 >>
position account using any amount of margin and you hit the exact >>
same issue as soon as you have more signals than available funds. >>
>> Even using the simplistic one position example, I believe that the
>> backtester would still THINK that there were enough funds available
>> to fill the BB signal since it IGNORES funds allocated to the AA
>> order that did not result in a signal. So, I think that your
> comment >> does not apply here and BB would in fact get
filled. >> >> The underlying problem is that AmiBroker does
not appear to have a >> way to model the fact that the broker will
commit funds to orders >> *placed*, even if those orders do not get
*filled*. If I am not >> mistaken, AmiBroker only considers funds
commited to a *filled* > order >> (i.e. a signal). >>
>> There are at least 3 other forum members that have written about
> this >> issue, so the scenario is real. >>
>> Based on my experiments so far, my code will correctly model the
>> scenario described. I was hoping for either A) a better solution,
> or >> B) validation that the code works for
others. >> >> Thanks, >> >>
Mike >> >> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko"
<groups@> >> wrote: >> > >> > I disagree
completely. >> > I am trading on REAL margin account in REAL life.
With 50% margin >> account >> > I am always able to place
limit orders for all signals I am > getting. >> >
>> > As to "cleaner" solution to theoretical example that you have
>> provided: >> > it is as easy as setting
"MaxOpenPositions" to ONE. >> > >> > You would end up
with no position open on Tuesday night (your >> desired
behaviour) because backtester >> > STOPS opening positions if
"top" signal can not enter due to lack >> of funds. >> >
>> > Best regards, >> > Tomasz Janeczko >>
> amibroker.com >> > ----- Original Message ----- >>
> From: "Mike" <sfclimbers@> >> > To: <amibroker@xxxxxxxxxxxxxxx> >> >
Sent: Tuesday, September 04, 2007 9:11 PM >> > Subject: [amibroker]
Re: How do I backtest placing a restricted >> number of limit orders
each night? >> > >> > >> > >
Tomasz, >> > > >> > > 1. Margin does not solve
the problem, it just delays it. As > soon >> as >>
> > you get one too many setups you hit the same problem again. >
Also, >> for >> > > aggressive strategies using full
margin, margin will already > have >> > > been accounted
for when placing the first 10 orders of my > example. >> >
> >> > > 2. When using a cash account you are not "DONE".
Your code will >> > > accept the top ten *SIGNALS*. The problem
is that the trader > can >> not >> > > afford
to place all the *ORDERS*. Your system will accept > signals >>
for >> > > orders that were *NEVER PLACED*. >> >
> >> > > To make this as simple as possible: >> >
> >> > > Monday day: >> > > - Have $5,000
available cash >> > > - Receive entry setup for AA, BB,
CC >> > > - PositionScore for AA > BB > CC >> >
> >> > > Monday night: >> > > - Place Tuesday
limit order for $5,000 AA (since highest score) >> > > - Have $0
available cash (broker immediately *reserved* $5,000 >> for
AA) >> > > - Can *not* afford to place limit order for BB,
CC >> > > >> > > Tuesday day: >> >
> - Limit order for AA *not* met >> > > - Limit for BB *would*
have been met, but order was *not* placed >> > > - Limit for CC
*would* have been met, but order was *not* placed >> > >
>> > > Tuesday night (YOUR CODE): >> > > -
Holding $5,000 of BB <--- Wrong! >> > > - $0 available
cash <--- Wrong! >> > > >>
> > Tuesday night (REAL LIFE): >> > > - No
holdings <---
Correct >> > > - $5,000 available cash <---
Correct >> > > >> > > In your code, I would be
filled for $5,000 of BB which *I never >> > > placed an order
for*. Your code correctly determined that there >> was >>
> > only room to buy 1 position (e.g. did not also buy CC), but it
>> used >> > > funds that were *not available*. All
funds were already used up >> by >> > > the limit
order placed for AA, so the signal for BB was >>
impossible. >> > > >> > > In my code, the signals
for BB and CC would be cancelled since >> their >> > >
PositionScores are *less* than the top PositionScore (AA) and I >>
only >> > > had room to place 1 order, regardless of the fact
that AA was >> never >> > > filled. The system now
correctly shows that there was no > *valid* >> > > signal
for BB and CC. >> > > >> > > If you have a
cleaner way to model this behavior, I would very >> much >>
> > like to use it. >> > > >> > >
Thanks, >> > > >> > > Mike >> > >
>> > > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko"
<groups@> >> > > wrote: >> >
>> >> > >> Hello, >> > >> >>
> >> In addition to the fact that if you are using MARGIN account
>> this >> > > is not a problem to place >>
> >> 15 orders because they will all be within your buying power
>> > > (including margin), >> > >> there is
one more thing: >> > >> if you are using cash account that
does not allow buying power >> >> > > cash >>
> >> the problem you are describing is non-existing. Just
define >> > >> SetOption("MaxOpenPositions", 10 ) >>
> >> and you are DONE. The code will accept only TEN TOP entry
>> signals >> > > and nothing more. >> >
>> (And instead of "exploration", you should use "Add artificial
>> > > future bar" in the settings and run BACKTEST >>
> >> with TOMMORROWS date to find out signals for
tommorrow). >> > >> >> > >> Best
regards, >> > >> Tomasz Janeczko >> > >>
amibroker.com >> > >> ----- Original Message -----
>> > >> From: "Mike" <sfclimbers@> >> >
>> To: <amibroker@xxxxxxxxxxxxxxx> >> >
>> Sent: Tuesday, September 04, 2007 7:00 PM >> > >>
Subject: [amibroker] Re: How do I backtest placing a > restricted
>> > > number of limit orders each night? >> >
>> >> > >> >> > >> >
Tomasz, >> > >> > >> > >> > You are
missing the problem. >> > >> > >> > >>
> Yes, setting a limit order is easy. The problem is that in >>
real >> > > life >> > >> > the broker will
*reserve the funds* necessary to fill a > limit >> > >
order >> > >> > *at the time that the order is placed*,
even if the order is >> > > never >> > >>
> filled. If the limit is not reached, the funds will only >>
become >> > >> > available again *after* the close of the
bar. >> > >> > >> > >> > Using
portfolio constraints, the sample that you have > provided >>
> > can be >> > >> > made to ensure that only 10
orders are *filled*. But, it >> assumes >> > > that
>> > >> > limit orders were *placed* for all setups. That
is not >> realistic. >> > >> > >> >
>> > So, if I have $50,000, I can only place 10 limit orders of
>> $5,000 >> > >> > each. If I receive more than
10 setups from the previous > bar, >> > > then I
>> > >> > do not have enough funds to place orders for all
of them and >> must >> > >> > choose the top 10
of 15. >> > >> > >> > >> > Since we
can only place *some* limit orders, the trading >> system >>
> > must >> > >> > recognize *which* limit orders
were placed, and ignore the >> rest. >> > >> >
>> > >> > To repeat, if I have only placed limit orders
for the top 10 >> > > setups, >> > >> >
then if the limit is not reached for any of those 10, I will >> have
>> > > 0 >> > >> > positions filled. The
price action of the remaining 5 is >> > >> > irrelevant. I
could not afford to place orders on all 15, so >> my >> >
>> > system must reflect that any fills of the remaining 5 *were
>> never >> > >> > placed* and must be
cancelled. >> > >> > >> > >> > Is
there a better way to model this behavior? >> > >> >
>> > >> > Thanks, >> > >> >
>> > >> > Mike >> > >> > >>
> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko"
> <groups@> >> > >> > wrote: >> >
>> >> >> > >> >> Solution was provided
before. It does not require any > custom >> > >> >
backtest code >> > >> >> and is actually
easy. >> > >> >> I repeat: >> > >>
>> >> > >> >> LimitPrice = >> >
>> >> Buy = your original buy rule >> > >>
>> >> > >> >> SetTradeDelays( 0, 0, 0, 0 ); // we
use zero delays but we >> use >> > > Ref >>
> >> > () to shift buy signal. >> > >> >>
>> > >> >> Buy = Ref( Buy, -1 ) AND Low <
LimitPrice; // this handles >> LIMIT >> > >> >
order >> > >> >> BuyPrice = Min( Open, LimitPrice ); //
this ensures >> limitprice >> > > is >> >
>> > used for entry or the Open price if it is lower than
limit >> > >> >> >> > >> >>
SetBacktestMode( backtestRegularRaw ); // this makes sure >> that
>> > >> > repeated signals occuring on many bars in
sequence are not >> ignored >> > >> >>
>> > >> >> >> > >> >> You
don't need to do anything as convoluted as you are >> > >
apparently >> > >> > doing in your formula >>
> >> >> as the code ABOVE handles placing limit orders (which are
>> only >> > >> > executed if >> >
>> >> price penetrates your desired limit level). >> >
>> >> >> > >> >> Best regards, >>
> >> >> Tomasz Janeczko >> > >> >>
amibroker.com >> > >> >> ----- Original Message -----
>> > >> >> From: "Mike" <sfclimbers@> >>
> >> >> To: <amibroker@xxxxxxxxxxxxxxx> >> >
>> >> Sent: Tuesday, September 04, 2007 9:08 AM >> >
>> >> Subject: [amibroker] Re: How do I backtest placing a
>> restricted >> > >> > number of limit orders
each night? >> > >> >> >> > >>
>> >> > >> >> > Hi, I am submitting the
following code for comment. I >> believe >> > >>
> that I >> > >> >> > have a generic solution for
the "fixed number of >> conditional >> > >> >
orders >> > >> >> > on next bar"
problem. >> > >> >> > >> > >>
>> > Constructive criticism is welcomed. Please feel free to
>> point >> > > out >> > >> >
any >> > >> >> > bugs, inefficiencies, suggested
enhancements, etc. >> > >> >> > >> >
>> >> > If this is deemed valuable, I can clean up the formatting
>> and >> > > add >> > >> > it
>> > >> >> > to the files section. >> >
>> >> > >> > >> >> > Mike >>
> >> >> > >> > >> >> > Problem
Statement: >> > >> >> >
------------------ >> > >> >> > Need programatic
support for simulating the placement of > a >> > > fixed
>> > >> >> > number of prioritized *conditional*
orders at the next > bar, >> in >> > >>
>> > response to one or more favorable "setups" triggered by >
the >> > >> > current >> > >> >>
> bar, and constrained by the number of positions permitted >> by
>> > > the >> > >> >> >
strategy. >> > >> >> > >> > >>
>> > Example: >> > >> >> >
-------- >> > >> >> > Consider a strategy that calls
for the placement of limit >> > > orders >> >
>> > at >> > >> >> > the next bar after
recognizing one or more favorable > setups >> on >>
> >> > the >> > >> >> > current bar.
Assume that the strategy allows a maximum of >> only >> >
> 10 >> > >> >> > open positions at any given
time, and that the setups are >> > >> > prioritized
>> > >> >> > from most preferred (position 1) to
least preferred >> (position >> > > 10). >>
> >> >> > >> > >> >> > If on the
first day of the strategy 20 favorable setups >> were >>
> >> >> > recognized, then the strategy would call for placing
> limit >> > > orders >> > >> > at
>> > >> >> > the next bar for *only* the top 10
preferred setups > (since >> > > only >> >
>> > 10 >> > >> >> > positions are
permitted and we can not know in advance >> whether >> >
>> > any or >> > >> >> > all of the 10
orders would actually get filled). >> > >> >> >
>> > >> >> > Similarly, if at some point after
starting the strategy > we >> > > found >> >
>> >> > ourself with 2 currently open positions and received 20
>> > > setups, >> > >> > we >>
> >> >> > would place 8 (10 - 2 = 8) limit orders for the top
8 >> > > preferred >> > >> >> >
setups. >> > >> >> > >> > >>
>> > Complications >> > >> >> >
------------- >> > >> >> > 1. Using PositionScore and
position sizing is not >> sufficient >> > >> >
since >> > >> >> > they do not recognize the
allocation of funds commited to >> > >> >> >
*conditional* order placements that do *not* get filled. >> >
>> > Resulting >> > >> >> > code would
typically continue to attempt to fill > allowable >> >
>> > position >> > >> >> > count despite
not having enough funds to cover all > possible >> >
>> > setups. >> > >> >> > >> >
>> >> > 2. Script execution for any given symbol does not have
>> access >> > > to >> > >> >
the >> > >> >> > PositionScore of the remaining
symbols. >> > >> >> > >> > >>
>> > 3. Custom backtester object does not have access to the
>> > >> > PositionScore >> > >>
>> > of any symbol that did *not* result in a generated trade
>> > > signal >> > >> > (i.e. >>
> >> >> > if a limit order was not met, the custom backtester
would >> not >> > >> > have a >> >
>> >> > signal object for that conditional placement, and thus
>> would >> > > not >> > >> >
have >> > >> >> > access to the PositionScore of the
unsuccessful order). >> > >> >> > >> >
>> >> > Solution >> > >> >> >
-------- >> > >> >> > 1. Generate a "composite"
symbol for each allowable >> position >> > > of
>> > >> > the >> > >> >> >
strategy (e.g. for a strategy allowing a maximum of 10 > open
>> > >> >> > positions, geneare composites
~Position1, > ~Position2, ..., >> > >> >> >
~Position10). >> > >> >> > >> > >>
>> > 2. At each bar of each symbol, calculate a PositionScore
>> for >> > > any >> > >> >>
> conditional order based on the recognition of a setup on >> the
>> > >> > previous >> > >> >>
> bar (e.g. PositionScore for a limit order in response to > a
>> > >> > recognized >> > >> >>
> setup the bar before). Note that this is a PositionScore >> for
>> > > the >> > >> >> >
*conditional* order which *may or may not* have been >> filled.
>> > > If >> > >> > no >> >
>> >> > setup was recognized in the previous bar the >
PositionScore >> > > would >> > >> > be
>> > >> >> > zero. >> > >>
>> > >> > >> >> > 3. Insert, in a sorted
manner, the calculated > PositionScore >> > > into
>> > >> > the >> > >> >> >
appropriate composite, bumping down in a chain reaction > any
>> > >> > current >> > >> >> >
composite occupants as needed. >> > >> >> >
>> > >> >> > For example; if the PositionScore for
the current symbol > at >> > > the >> >
>> >> > current bar was found to be less than the value held by
>> > >> > ~Position1 >> > >> >>
> for that bar, the comparrison would next be made against >> >
>> > ~Position2. >> > >> >> > If the
PositionScore was found to be greater than the > value >> >
> held >> > >> > by >> > >> >>
> ~Position2 for that bar, then the value for that bar of >> >
>> > ~Position2 >> > >> >> > would be
replaced (bumped) by PositionScore, and the > value >> >
> that >> > >> > had >> > >>
>> > been in ~Position2 would be moved down to ~Position3 for
>> that >> > >> > same >> >
>> >> > bar, bumping down any value held by ~Position3 in a chain
>> > >> > reaction >> > >> >>
> until a zero composite value was found (i.e. nothing to >> bump)
>> > > or >> > >> > all >> >
>> >> > composites had been updated. >> > >>
>> > >> > >> >> > e.g. given: >>
> >> >> > >> > >> >> >
PositionScore[x] is 99 and; >> > >> >> > >>
> >> >> > ~Position1[x] is 100 >> > >>
>> > ~Position2[x] is 50 >> > >> >> >
~Position3[x] is 49 >> > >> >> > ~Position4[x]
is 0 >> > >> >> > ... >> >
>> >> > ~Position10[x] is 0 >> > >>
>> > >> > >> >> > Result after insertion
would be: >> > >> >> > >> > >>
>> > ~Position1[x] is 100 >> > >> >> >
~Position2[x] is 99 >> > >> >> > ~Position3[x]
is 50 >> > >> >> > ~Position4[x] is
49 >> > >> >> > ~Position5[x] is
0 >> > >> >> > ... >> > >> >>
> ~Position10[x] is 0 >> > >> >> >
>> > >> >> > 4. Write custom backtester logic to
calculate, at each > bar, >> > > how >> >
>> > many >> > >> >> > open positions
exist, and reset to 0 the PosSize of any >> Signal >> >
>> > whose >> > >> >> > PositionScore is
*less* than the PositionScore held by > the >> N- >>
> > th >> > >> >> > composite, where N is
calculated as max allowed positions >> > > minus >>
> >> > the >> > >> >> > number of
currently opened positions (e.g. 10 max >> positions - >>
> > 2 >> > >> > open >> > >>
>> > positions = composite ~Position8). This emulates not >
having >> > >> > placed >> > >>
>> > orders for any but the top N preferred setups. >> >
>> >> > >> > >> >> > 5. Leave to the
native backtester all other decisions >> > > regarding
>> > >> > enty >> > >> >> >
into positions and tie-breaking of equal PositionScore. >> >
>> >> > >> > >> >> >
Advantages >> > >> >> > ---------- >> >
>> >> > 1. Works generically for any conditional strategy, Long
> or >> > > Short*. >> > >> >>
> 2. Works equally well for scale-in strategies. >> > >>
>> > 3. Makes no assumptions regarding Buy/Sell rules. >> >
>> >> > 4. Does not result in any phantom/artificial
trades. >> > >> >> > 5. Does not generate any
phantom/artificial commisions. >> > >> >> > 6. Does
not depend on any backtester settings "tweaks". >> > >>
>> > 7. PositionScore data is available at all times for >>
additional >> > >> >> > analysis. >> >
>> >> > >> > >> >> > * Backtester
logic must be custom fit to your strategy, > but >> >
>> >> > persistence of scores is generic to all. >> >
>> >> > >> > >> >> >
Disadvantages >> > >> >> > ------------- >>
> >> >> > 1. Slower execution resulting from heavy looping
(loops N >> > > times >> > >> > more
>> > >> >> > than alternative proposed in msg
#113384, where N equals >> > > maximum >> >
>> >> > allowed positions). >> > >> >>
> >> > >> >> > For example; A strategy backtested
3 months over 7800+ >> symbols >> > >> > using
>> > >> >> > 10 allowed positions on a 1.4Ghz laptop
with 1GB RAM > takes >> > > about >> >
>> > 10 >> > >> >> > minutes. >>
> >> >> > >> > >> >> > 2. Code is
more complex than alternative proposed in msg >> > >
#113384. >> > >> >> > >> > >>
>> > ----- >> > >> >> > ----- Sample code
snippets for your review (Long only) >> > >> >> >
----- I have left in _TRACE statements to see what's >>
happening >> > >> >> > ----- >> >
>> >> > >> > >> >> > /* >>
> >> >> > * Carry fixed number of positions, equally
divided. >> > >> >> > */ >> > >>
>> > maxPositions = 10; >> > >> >> >
PositionSize = -100/maxPositions; >> > >> >> >
SetOption("MaxOpenPositions", maxPositions); >> > >> >>
> >> > >> >> > /* >> > >>
>> > * Custom backtester implementation to strip out orders >
that >> in >> > >> >> > * reality would not
have been placed due to a limitation > of >> > >>
>> > * available capital to cover bids on all setups. >> >
>> >> > * >> > >> >> > * Note: This
implementation assumes Long positions only! >> > >> >>
> */ >> > >> >> >
SetCustomBacktestProc(""); >> > >> >> > >>
> >> >> > if (Status("action") == actionPortfolio)
{ >> > >> >> > bo =
GetBacktesterObject(); >> > >> >> >
bo.PreProcess(); >> > >> >> > >> >
>> >> > for (bar = 0; bar < BarCount; bar++)
{ >> > >> >> > openCount =
0; >> > >> >> > >> > >> >>
> for (openPos = bo.GetFirstOpenPos(); >> >
>> >> >
openPos; >> > >> >>
> openPos =
bo.GetNextOpenPos()) >> > >> >> >
{ >> > >> >> >
openCount++; >> > >> >> >
} >> > >> >> > >> > >> >>
> minPos = maxPositions - openCount; >> >
>> >> > posScores = IIF(minPos, >>
> >> >>
>
Foreign("~Position" + minPos, "X", 0), >> > >> >>
>
9999); // Highest possible score! >> > >> >> >
>> > >> >> > for (sig =
bo.GetFirstSignal(bar); >> > >> >>
> sig; >> >
>> >> > sig =
bo.GetNextSignal(bar)) >> > >> >> >
{ >> > >> >> > if
(sig.IsEntry() AND sig.IsLong()) { >> > >> >>
> if (sig.PosScore <
posScores[bar]) { >> > >> >>
>
/*_TRACE(StrFormat("Score %9.4f less than top % >> 1.0f >>
> >> > scores >> > >> >> > of %9.4f at
bar %5.0f, cancel signal for ", sig.PosScore, >> > > minPos,
>> > >> >> > posScores[bar], bar) +
sig.Symbol);*/ >> > >> >> > >> >
>> >> > //
Order would not have been placed, cancel it > out. >> >
>> >> >
sig.PosSize = 0; >> > >> >>
> } >> > >>
>> > } >> > >> >>
> } >> > >> >> > >>
> >> >> >
bo.ProcessTradeSignals(bar); >> > >> >> >
} >> > >> >> > >> > >> >>
> bo.PostProcess(); >> > >> >> >
} >> > >> >> > >> > >> >>
> /* >> > >> >> > * For each bar following entry
setup, persist > PositionScore >> > > into >>
> >> > an >> > >> >> > * ordered list of
Foreign symbols such that we may later >> have >> >
>> > access >> > >> >> > * to the top scores
during backtesting, regardless of >> whether >> > > a
>> > >> >> > * concrete signal for the ranked symbol
is actually > found. >> See >> > >> >>
> * custom backtester method for filtering logic. >> > >>
>> > * >> > >> >> > * For example; a 10
position, limit order strategy >> currently >> > >>
> holding >> > >> >> > * 2 positions might place
limit orders for only the top 8 >> > > setups, >> >
>> >> > * despite recognizing more than 8 candidate setups. This
>> > > method >> > >> >> > * would
sort the PositionScore of all candidate setups > into >>
10 >> > >> >> > * foreign symbols, regardless of
whether or not the limit >> > > order >> > >>
> was >> > >> >> > * met. The backtester would
then compare the > PositionScore >> of >> > >
all >> > >> >> > * filled signals (i.e. all signals
of the limit price >> having >> > > been >>
> >> >> > * met), and cancel out those whose score was less
than > the >> top >> > > 8 >> >
>> >> > * scores found in the Foreign symbols (i.e. cancel out
>> signals >> > >> > for >> >
>> >> > * those symbols upon which, in reality, a limit order
> would >> > > never >> > >> >>
> * actually have been placed). >> > >> >> >
* >> > >> >> > * Note: This implementation leaves the
responsibility of >> tie- >> > >> >> > *
breaking to the backtester, when multiple symbols have >> the
>> > > same >> > >> >> > *
PositionScore for a limited number of available >> positions.
>> > > The >> > >> >> > * symbol
selected by the backtester may not be the one > for >> >
> which >> > >> > an >> > >>
>> > * order was actually placed in real life. But, the symbol
>> > >> > selected >> > >> >>
> * is guaranteed to at least have an equivalent >> PositionScore.
>> > > Use >> > >> >> > * unique
PosittionScore values, or trade in real life > using >> >
> the >> > >> > same >> > >> >>
> * tie-breaking logic that AmiBroker uses :) >> > >>
>> > * >> > >> >> > * Note: This
implementation assumes that PositionScore > will >> be
>> > >> >> > * either zero, for bars not recognized
as following order >> > >> > placement >> >
>> >> > * criteria (i.e. no setup from previous bar), or a non
> zero >> > >> > positive >> > >>
>> > * number, for bars where order placement criteria has >
been >> > > met. To >> > >> >> > *
reiterate, this refers to order *placement* criteria >> (i.e.
>> > >> > setup), >> > >> >> >
* not order *fulfillment*. >> > >> >> >
*/ >> > >> >> > procedure persistScores(scores)
{ >> > >> >> > local maxPositions; // Max
positions allowed in portfolio >> > >> >> >
local empty; // Array of
zeros >> > >> >> > local
bar; // Loop
variable >> > >> >> > local
score; // PositionScore of bar-th
bar >> > >> >> > local
pos; // Loop
variable >> > >> >> > local
composite; // Name of pos-th composite >> >
>> >> > local posScores; // Scores
persisted to composite >> > >> >> > local
delta; // Delta between PositionScore
and >> > > composite >> > >> >>
> local affected; // Flag whether any deltas
were added >> > >> >> > >> > >>
>> > maxPositions = GetOption("MaxOpenPositions"); >>
> >> >> > empty = Cum(0); >> > >>
>> > >> > >> >> > for (pos = 1; pos
<= maxPositions; pos++) { >> > >> >>
> /*_TRACE("Persist " + Name() + " to position " + >
pos);*/ >> > >> >> > composite =
"~Position" + pos; >> > >> >> >
AddToComposite(0, composite, "X", 1 + 2 + 4 + 8); // >> >
>> > Initialize >> > >> >>
> posScores = Foreign(composite, "X", 0); // Do not
> fill >> > > holes! >> > >> >>
> delta = empty; >> > >> >>
> affected = false; >> > >> >> >
>> > >> >> > for (bar = 0; bar
< BarCount; bar++) { >> > >> >>
> if (scores[bar]) { >> > >>
>> > score =
scores[bar]; >> > >> >> > >> > >>
>> > if (score >
posScores[bar]) { >> > >> >>
>
/*_TRACE(StrFormat("Score %9.4f bumps down >> position % >>
> >> > 1.0f >> > >> >> > score of %9.4f
at bar %5.0f", score, pos, posScores[bar], >> > >
bar));*/ >> > >> >> > >> > >>
>> > // Grab
current best value and hold for next >> composite >> >
>> >> > //
iteratation, and calculate delta needed to > add >> to
>> > >> >>
> // this composite in
order to make it equal new >> high >> > >> >
score >> > >> >> > >> > >>
>> > scores[bar]
= posScores[bar]; >> > >> >>
> delta[bar] = score -
posScores[bar]; >> > >> >>
> affected =
true; >> > >> >>
> } >> > >>
>> > /*else if
(posScores[bar]) _TRACE(StrFormat("Score > % >> > > 9.4f
>> > >> >> > blocked by position %1.0f score of
%9.4f at bar %5.0f", >> score, >> > >> > pos,
>> > >> >> > posScores[bar], bar));*/ >>
> >> >> > } >> >
>> >> > } >> > >> >>
> >> > >> >> > if (affected)
{ >> > >> >> >
AddToComposite(delta, composite, "X", 1 + 2 + 4 + 8); >> > >>
>> > } >> > >> >> >
} >> > >> >> > >> > >> >>
> /*_TRACE("\n");*/ >> > >> >> >
} >> > >> >> > >> > >> >>
> setup =
...
// Some setup recognition > logic >> > >> >> >
Buy = Ref(setup, -1) AND ... // Some conditional entry >
logic >> > >> >> > PositionScore = IIF(Ref(setup,
-1), ..., 0); // Some > score >> > > logic >>
> >> > or 0 >> > >> >> > Sell =
...
// Some Sell logic >> > >> >> > >> >
>> >> > persistScores(PositionScore); >> > >>
>> > >> > >> >> > /* >> >
>> >> > * Example of 5% dip limit conditional entry: >>
> >> >> > * BuyPrice = min(Open, (Ref(Close, -1) *
0.95)); >> > >> >> > * Buy = Ref(setup,
-1) AND Low <= BuyPrice; >> > >> >> >
*/ >> > >> >> > >> > >> >>
> ------ >> > >> >> > ------ End code
snippets >> > >> >> > ------ >> >
>> >> > >> > >> >> > --- In amibroker@xxxxxxxxxxxxxxx, "ed2000nl" >
<empottasch@> >> > > wrote: >> > >>
>> >> >> > >> >> >> i'll try to reply
directly from yahoo. My posts aren't >> coming >> >
>> >> > through >> > >> >> >>
anymore. Might be because of the ISP ... >> > >> >>
>> >> > >> >> >> >> > >>
>> >> so if I understand correctly the problem is not that the
>> > >> > backtester >> > >> >>
>> picks 20 stocks while there is only money for 10 but > you
>> > > have a >> > >> >> >
problem >> > >> >> >> with the fact that if
the 10 actual signals are not >> filled >> > > it
>> > >> > will >> > >> >> >
use >> > >> >> >> the lower ranking 10
signals and this is not what you >> > > want.
>> > >> > You >> > >> >> >
can >> > >> >> >> include this in the backtester.
I explained the same > thing >> > > some
>> > >> >> > time >> > >> >>
>> ago. For signals that you actually want to enter but in >>
real >> > >> > life >> > >> >>
> will >> > >> >> >> not be entered
because the limit is not reached then > you >> can >>
> >> > tell >> > >> >> > the >>
> >> >> >> backtester to enter at the open and exit
at the open > and >> do >> > > not >>
> >> >> > allow >> > >> >> >>
for a single bar trade (in the settings window). >
There >> > > might >> > >> >
be >> > >> >> >> easier ways to do this (I mean
using arrays only) but I >> have >> > >> >
some >> > >> >> >> example code below. I did not
check if the code is >> entirely >> > >> >
correct >> > >> >> > but >> > >>
>> >> I'll explain the idea: The Buy array is fed to the
>> > > sellAtLimit >> > >> >> >
procedure >> > >> >> >> and when it finds a
buy it will check if the buy limit > is >> > >> >
reached >> > >> >> > for >> > >>
>> >> that signal. If it is not reached (so if Low[ i ] >=
>> buyLimit >> > > [ >> > >>
>> > i ] ) >> > >> >> >> then you tell
the backtester to enter and exit at the >> same >>
> >> > price, >> > >> >> >
same >> > >> >> >> bar. What happens is that the
backtester reserves this >> money >> > >>
> for >> > >> >> > this >> > >>
>> >> trade and will not use it for another trade. The only
>> thing >> > >> > that >> >
>> >> > is not >> > >> >> >>
realistic is that you will pay commission. But this > will
>> be >> > > a >> > >> >
small >> > >> >> >> factor. rgds,
Ed procedure >> > >> >>
>> sellAtLimit_proc(Buy,BuyPrice,buyLimit,sellLimit) { >> >
>> >> >> >> > >> >> >> global
Sell; >> > >> >> >> global SellPrice; >>
> >> >> >> global BuyAdjusted; >> > >>
>> >> global BuyPriceAdjusted; >> > >> >>
>> >> > >> >> >> >> > >>
>> >> // initialise arrays >> > >> >>
>> SellPrice = 0; >> > >> >> >> Sell =
0; >> > >> >> >> BuyAdjusted =
0; >> > >> >> >> BuyPriceAdjusted = 0; >>
> >> >> >> >> > >> >> >> for
(i = 1; i < BarCount; i++) { >> > >> >>
>> >> > >> >> >> >> > >>
>> >> // case where it is likely to enter
a long position >> > >> >>
>> if (Buy[ i ] == 1 AND Low[ i ] <
buyLimit[ i ]) { >> > >> >> >> >> >
>> >> >> >> > >> >>
>> // buy at limit >>
> >> >> >>
BuyAdjusted[ i ] = 1; >> > >> >> >>
>> > >> >>
>> if (Open[ i ] <
buyLimit[ i ]) { >> > >> >> >> >> >
>> >> >> >> > >> >>
>>
BuyPriceAdjusted[ i ] = Open[ i ]; >> > >> >> >>
>> > >> >>
>> } else { >> >
>> >> >> >> > >> >>
>>
BuyPriceAdjusted[ i ] = buyLimit[ i ]; >> > >> >>
>> >> > >> >>
>> } >> > >>
>> >> >> > >> >> >> >> >
>> >> >> // find a
sell position + sellprice >> > >> >>
>> for (j = i; j < BarCount;
j++) { >> > >> >> >> >> > >>
>> >> if
(O[ j ] > sellLimit[ j ]) { >> > >> >> >>
>> > >> >>
>>
Sell[ j ] = 1; >> > >> >>
>>
SellPrice[ j ] = O[ j ]; >> > >> >>
>>
i = j; >> > >> >>
>>
break; >> > >> >> >> >> > >>
>> >> }
else if (O[ j ] < sellLimit[ j ] AND H[ j ] >> >>
> >> > sellLimit >> > >> >> > [
j >> > >> >> >> ]) { >> > >>
>> >> >> > >> >>
>>
Sell[ j ] = 1; >> > >> >>
>>
SellPrice[ j ] = sellLimit[ j ]; >> > >> >>
>>
i = j; >> > >> >>
>>
break; >> > >> >> >> >> > >>
>> >> }
else if (j == BarCount - 1) { >> > >>
>> >> >> > >> >>
>>
i = BarCount; >> > >> >> >> >> >
>> >>
>>
} >> > >> >> >> >> > >>
>> >> >> > >> >> >> >> >
>> >> >> >> > >> >> >>
>> > >> >>
>> } >> > >>
>> >> >> > >> >>
>> } else if (Buy[ i ] == 1 AND Low[ i
] >= buyLimit[ >> i ]) >> > > { >> >
>> >> >> >> > >> >>
>> // enter and exit at the same
price and time >> ("VOID" >> > >> >
trade) >> > >> >>
>> BuyAdjusted[ i ] =
1; >> > >> >>
>> BuyPriceAdjusted[ i ] = Open[
i ]; >> > >> >> >> >> > >>
>> >> Sell[ i ] =
1; >> > >> >>
>> SellPrice[ i ] = Open[ i
]; >> > >> >> >> >> > >>
>> >> >> > >> >>
>> } >> > >> >> >>
>> > >> >> >> } >> > >>
>> >> >> > >> >> >> >> >
>> >> >> } // end procedure >> > >>
>> >> >> > >> >> >> >> >
>> >> >> --- In amibroker@xxxxxxxxxxxxxxx, "sfclimbers"
>> <sfclimbers@> >> > >> >
wrote: >> > >> >> >> > >> >
>> >> >> > Thanks for your reply. I will look into your
> suggestion, >> > > but I >> > >>
>> > don't >> > >> >> >> > think that
that is the issue that I am up against. I >> have >> >
>> > actual >> > >> >> >> > trade data
from months of live trading. I am now > trying >> to
>> > >> >> > backtest >> > >>
>> >> > the strategy used, and match the results to the actual
>> data. >> > >> >> >> > >>
> >> >> >> > My script, as written, is correctly
entering and > exiting >> > > with >> >
>> > the >> > >> >> >> > correct
number of shares and correct price points on > all >> > >
the >> > >> >> > correct >> > >>
>> >> > days for all the trades that actually took
place. >> > >> >> >> > >> >
>> >> >> > The problem is that if I receive 20 "go long"
signals > on >> > > Monday >> > >>
>> >> > night, but only have enough money to afford 8 more
>> > > positions, >> > >> >> > then
in >> > >> >> >> > real life I only place limit
orders for the *top* 8 of >> the >> > > 20 >>
> >> >> >> > candidates, not all 20. >> >
>> >> >> > >> > >> >> >> >
This means that in reality, if none of the top 8 dip > to >> my
>> > >> > limit >> > >> >>
>> > order, then I will not get any fills on Tuesday, even >>
> > though I >> > >> >> > still >>
> >> >> >> > have not filled my slots, and even though
some of the >> lesser >> > >> >> >> >
candidates would have resulted in a fill had I place > an >>
> > order >> > >> > for >> > >>
>> >> > them. >> > >> >> >>
> >> > >> >> >> > However, the script is
considering *all* 20 > candidates, >> and >> >
>> > fills >> > >> >> > up >> >
>> >> >> > to 8 that dip enough to trigger a limit order.
In > other >> > > words, >> > >> >
the >> > >> >> >> > script assumes that there
are limit orders on all >> > > candidates >> >
>> >> > instead >> > >> >> >> >
of only the top 8. >> > >> >> >> > >>
> >> >> >> > Using position score and position sizing is
not > enough, >> > > since >> > >>
>> > these >> > >> >> >> > assume that
the universe of candidates fitting the >> criteria >> >
> is >> > >> >> > always >> >
>> >> >> > available for prioritizing and filling available
> slots. >> > > But, in >> > >>
>> >> > reality, only a subset are being bid on. >> >
>> >> >> > >> > >> >> >> >
As an example, if I'm currently holding: >> > >> >>
>> > AAA, BBB >> > >> >> >>
> >> > >> >> >> > And I then get signals for
(in sorted order): >> > >> >> >> > CCC, DDD,
EEE, FFF, GGG, HHH, III, JJJ, KKK, LLL, ... > TTT >> >
>> >> >> > >> > >> >> >> >
I will only place limit orders for the top 8: >> > >> >>
>> > CCC, DDD, EEE, FFF, GGG, HHH, III, JJJ >> > >>
>> >> > >> > >> >> >> > If none
of the top 8 above reach my limit, but say 8 >> lesser >>
> >> > ones >> > >> >> > do >>
> >> >> >> > (that I did not bid on), then in real life
I will get > no >> > > fills >> > >>
> for >> > >> >> >> > the day. However, my
script is saying that I picked up >> the >> > > 8
>> > >> >> > lesser >> > >>
>> >> > fills since I had 8 slots open and these 8 met the
> limit >> > > price. >> > >> >>
>> > >> > >> >> >> > How can I
structure my code to recognize that 20 entry >> > > setups
>> > >> > were >> > >> >> >>
> found, but only 8 of them were acted upon, none of > which
>> > >> > actually >> > >> >>
>> > worked out due to not meeting the limit price? >> >
>> >> >> > >> > >> >> >> >
I can't seem to use the custom backtester to sweep >> through
>> > > the >> > >> >> >
orders >> > >> >> >> > and null out the false
buys that would not have taken >> > > place, >> >
>> >> > since I >> > >> >> >> >
don't have access to the scores of the candidates that >> > >
didn't >> > >> > get >> > >> >>
>> > filled. >> > >> >> >>
> >> > >> >> >> > Yet, similarly, I can't
seem to prevent triggering the >> buys >> > > in
>> > >> > the >> > >> >> >>
> first place, since I don't have access to the scores > of
>> the >> > >> > other >> > >>
>> >> > candidates at that time either. >> > >>
>> >> > >> > >> >> >> > When
there are fewer signals than slots to fill, >> everything >>
> > is >> > >> >> >> > great :) But this
strategy often results in more > signals >> > > than
>> > >> >> > there >> > >>
>> >> > is money to bid with :( >> > >>
>> >> > >> > >> >> >> >
Thanks. >> > >> >> >> > >> >
>> >> >> > >> > >> >> >> >
--- In amibroker@xxxxxxxxxxxxxxx, "Edward Pottasch"
>> > > empottasch@ >> > >> >> >>
> wrote: >> > >> >> >> > > >>
> >> >> >> > > hi, >> > >> >>
>> > > >> > >> >> >> > > the way
you set it up it shoudl not be possible. >> However, >> >
>> > what >> > >> >> > can >> >
>> >> >> > happen is that the backtester finds exits for
the next >> day >> > > and >> > >>
>> >> > immediatelly fills them with new positions. So you
> need >> to >> > >> > make >>
> >> >> > sure >> > >> >> >>
> that you first exit your positions and tell the >> backtester
>> > > to >> > >> >> >
enter >> > >> >> >> > only on the next bar.
This is usually the problem. >> There >> > > are
>> > >> >> > several >> > >>
>> >> > ways to achieve this. Maybe you will get a more
>> > > satisfactory >> > >> >> >
result >> > >> >> >> > when you set
settradedelays(1,1,1,1). >> > >> >> >> >
> >> > >> >> >> > > I use
setttradedelays(0,0,0,0) but I make sure that >> the >> >
>> > trade is >> > >> >> >> > entered
1 bar after the signal (same with the exits), >> > >> >>
>> > > >> > >> >> >> > >
Ed >> > >> >> >> > > >> >
>> >> >> > > >> > >> >> >>
> > >> > >> >> >> > > >> >
>> >> >> > > ----- Original Message
----- >> > >> >> >> > > From:
Michael White >> > >> >> >> > >
To: amibroker@xxxxxxxxxxxxxxx >> >
>> >> >> > > Sent: Friday, August 24, 2007
11:37 AM >> > >> >> >> > >
Subject: [amibroker] How do I backtest placing a >> > >
restricted >> > >> >> >> > number of limit
orders each night? >> > >> >> >> >
> >> > >> >> >> > > >> >
>> >> >> > > Can anyone help me model the
following scenario? >> > >> >> >> >
> >> > >> >> >> > > - Assume
a portfolio is allowed to consist of some >> > > fixed
>> > >> >> > number >> > >>
>> >> > > of "slots" with equity equally divided
among them >> (e.g. >> > > 10 >> >
>> >> > slots >> > >> >> >> >
at >> > >> >> >> > > 10% of
equity). >> > >> >> >> > > -
Check for setup criteria at close of each day. >> > >>
>> >> > > - Place next day limit buy orders for as
many >> unfilled >> > >> > slots >>
> >> >> > as >> > >> >> >> >
are >> > >> >> >> > > currently
available (e.g. if already have 2 fills >> after >> >
>> > day 1, >> > >> >> >> >
then >> > >> >> >> > > there are
only 10 - 2 = 8 slots remaining for day > 2, >> > >
etc.). >> > >> >> >> > > - Buy
orders are prioritized by a calculated value. >> > >> >>
>> > > >> > >> >> >> >
> My problem is that if I receive a setup for more >>
> > symbols >> > >> > than >> >
>> >> > I >> > >> >> >> >
have >> > >> >> >> > > available
slots (e.g. receive 20 setups but only >> have 8 >> >
>> >> > available >> > >> >> >>
> > slots), my script will try to fill all 8 slots >
from >> the >> > > 20 >> > >>
>> >> > > candidates, and the portfolio manager
will > correctly >> > >> > prevent >>
> >> >> > me >> > >> >> >> >
from >> > >> >> >> > > having
more positions than allowed (e.g. no more >> than >> >
> 10). >> > >> >> >> > > >> >
>> >> >> > > However, in reality, I will
only have placed as > many >> > > limit >> >
>> >> > orders >> > >> >> >> >
as >> > >> >> >> > > I have
available slots (e.g. 8 limit orders when 8 >> > >> >
available >> > >> >> >> > slots, >>
> >> >> >> > > not limit orders for all
20 candidates, since I > only >> > > have >>
> >> >> > funds >> > >> >> >>
> to >> > >> >> >> > > cover
placing 8 orders). >> > >> >> >> >
> >> > >> >> >> > > What is
happening is that my script is filling >> orders >> >
> that >> > >> > I >> > >> >>
>> > would >> > >> >> >> >
> not have placed! I need a way to indicate that >>
despite >> > > 20 >> > >> >> >
setups, >> > >> >> >> > > only 8
limit orders were placed. >> > >> >> >> >
> >> > >> >> >> > > Following
is some script snippets. >> > >> >> >> >
> >> > >> >> >> > >
/* >> > >> >> >> > > * Assume an
initial purse and brokerage fees >> > >
($0.01/share) >> > >> >> >> > >
*/ >> > >> >> >> > >
SetOption("InitialEquity", 50000); >> > >> >> >>
> > SetOption("CommissionMode", 3); >> > >>
>> >> > > SetOption("CommissionAmount",
0.01); >> > >> >> >> > > >> >
>> >> >> > > /* >> > >>
>> >> > > * Carry fixed number of positions,
dividing 100% > of >> > > Equity >> >
>> >> > between >> > >> >> >> >
> * them (based on previous bar's closing). >> >
>> >> >> > > */ >> > >>
>> >> > > PositionSize = -100/10; // Each position
is 10% of >> > > equity >> > >> >>
>> > > >> > >> >> >> >
> SetOption("MaxOpenPositions", 10); // No more than >>
10 >> > >> >> > positions >> > >>
>> >> > >
SetOption("UsePrevBarEquityForPosSizing", True); >> > >>
>> >> > > >> > >> >> >> >
> /* >> > >> >> >> >
> * We recognize the sale signal at the close of a > bar
>> > > and >> > >> >> >
execute >> > >> >> >> > the >> >
>> >> >> > > * sale at the open of the next
one, delay sale by > 1 >> day. >> > >>
>> >> > > */ >> > >> >>
>> > > SetTradeDelays(0, 1, 0, 0); >> >
>> >> >> > > >> > >> >> >>
> > /* >> > >> >> >> >
> * Trigger a Buy signal when previous bar meets the >>
setup >> > >> >> >> > > *
requirements AND this bar's Low has dropped to >> less >>
> > than >> > >> > a >> > >>
>> > fixed >> > >> >> >> >
> * percentage below the previous bar's close. This >>
> > emulates >> > >> >> > having >>
> >> >> >> > > * placed a limit order the
night before after > having >> > > seen >> >
>> > the >> > >> >> >> >
signal >> > >> >> >> > > * on
that day's close. >> > >> >> >> >
> */ >> > >> >> >> >
> setup = ... // Some position entry logic. >> >
>> >> >> > > PositionScore = ... // Some
prioritization logic. >> > >> >> >> >
> >> > >> >> >> > > BuyPrice
= Ref(Close, -1) * 0.95; >> > >> >> >> >
> Buy = Ref(setup, -1) AND Low <= BuyPrice; // >
Problem >> > >> > here!!! >> > >>
>> >> > > >> > >> >> >> >
> Sell = ... // Some sell logic. >> > >>
>> >> > > >> > >> >> >> >
> As indicated in my earlier comments. The problem > is
>> > > that in >> > >> >> >> >
reality I >> > >> >> >> > > will
not actually have placed orders for all >> > > candidates,
>> > >> > but >> > >> >> >>
> rather >> > >> >> >> > >
only for as many as there are available slots > (e.g. >> 8).
>> > >> >> > However, >> > >>
>> >> > the >> > >> >> >> >
> script will attempt to fill the available slots >>
based >> > > on >> > >> > all >>
> >> >> >> > > candidates (e.g.
20). >> > >> >> >> > > >> >
>> >> >> > > How can I restrict the Buy
assignment to only > apply >> to >> > > the
>> > >> >> > top X >> > >>
>> >> > of Y >> > >> >> >> >
> candidates based on priority (e.g. top 8 of 20 in >>
> > example >> > >> >> > above). >>
> >> >> >> > > >> > >> >>
>> > > Thanks in advance. >> > >>
>> >> > > >> > >> >> >>
> >> > >> >> >> >> > >>
>> > >> > >> >> > >> >
>> >> > >> > >> >> > >>
> >> >> > 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 >> > >> >> > >> > >>
>> > >> > >> >> > >> >
>> >> > >> > >> >> > >> >
>> >> >> > >> > >> > >> >
>> > >> > >> > >> > >>
> >> > 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 >> > >> > >> > >> >
>> > >> > >> > >> > >>
> >> > >> > >> >> > > >>
> > >> > > >> > > >> > >
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 >> > >
>> > > >> > > >> > >
>> > > >> > >> > > >
> > 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/ > > >
__._,_.___
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
__,_._,___
|