Brian,
Yes there are two pieces. The number of bars loaded, and the
number
of bars used in an array calculation. Both are important for speed,
but the number used for array calculations can make the most
difference
if it can be reduced. It would take a comprehensive
discussion of all the
different possibilities and what could be gained
be each one to clarify all
the issues. Bruce hinted that that has
already taken place in the past with
TJ. My simplest case is just to
allow the SBR in future passes to reduce the
number of bars like
possible on the first
pass.
BR,
Dennis
On Jun 30, 2009, at 5:44 AM, brian_z111
wrote:
> Clarification:
>
> The longest SBR, of the
complete formula, could be the primary
> (global)SBR, and control the #
bars loaded into memory,
> while the secondary SBR's set how many of the
bars already loaded
> into memory to actually use, for any particular
block of code (as
> defined by the local
SBR's???????????????????????????????????????
>
>
>
>
--- In amibroker@xxxxxxxxxps.com,
"brian_z111" <brian_z111@...> wrote:
>>
>> I still
have a few questions about this.
>>
>>
FTR:
>>
>> I am OK with the idea so far ... I am wondering
about the
>> practicality of the implementation though... I guess you
guys
>> (Fred,Bruce,Dennis), being programmers, are confident you
are going
>> to gain time, either when running long BT's or Opts OR
only in RT
>> charts?
>>
>> Does anyone have any
idea where these gains would come from, or how
>> they could be
achieved, in processing terms .... what sort of time
>> gains can we
expect if Tomasz does decide to action the idea?
>>
>> When
Dennis said that calling SBR with a lower # bars RESTARTS the
>>
charts I am guessing that he means bars are reloaded into memory,
>>
thus rebuilding the charts.... is this the default
behaviour?
>>
>> .. if so this would be the default for any
change of setting
>> (either up or down) so any change of setting has
this 'penalty'
>> attached?
>>
>> Are you guys
suggesting that, where two or more calls are made to
>> SBR() that AB
could still estimate max bars required for the
>> longest SBR after
the first pass, keep them in memory, but only
>> access the number
required for each subsequent block of shorter
>> length arrays ....
i.e. where there are more than one SBR in a
>> formula, the longest
SBR will be the primary SBR, and control the #
>> bars loaded, while
the secondary SBR's set how many of the loaded
>> bars to actually
use?
>>
>> I don't know if instructing AB to change to using,
say, 10 bars,
>> from a loaded memory of, say, 100, has much of a time
penalty
>> attached to it ... I guess not?
>>
>> I
don't understand how processors work so I am not certain that
>> this
would lead to a time gains ... I guess if there are gains to
>> be
had, by this method, it would depend on how long it takes to
>> change
the no bars actually processed and ... how many lines of
>> code are
included in the short array block.
>>
>> I assume that
processing 10 bars, already in memory, is actually
>> faster than
processing the whole 100, already in memory .... that
>> is a big
assumption on my part (could be wrong!).
>>
>> Is that what
you guys are suggesting or is it something
else?
>>
>>
>>
>>
>> --- In amibroker@xxxxxxxxxps.com,
Dennis Brown <see3d@> wrote:
>>>
>>>
Bruce,
>>>
>>> Thanks for your suggestions. They are
appreciated. I will contact
>>> you off-line for further discussion
about these.
>>>
>>> I am glad to see that I am not the
only one who would like to have
>>> more control over the number of
bars used in AFL. I posted one bug
>>> related to these long ago,
and commented on the one way nature of
>>> SBR,
>>> but
never posted my own suggestion for having the ability to reduce
>>>
the number of bars via SBR, because I previously could not get
any
>>> responses from this forum or support about how I should go
about
>>> trying to do this. I did not want to suggest something
without
>>> knowing it was desired by more than myself, or
understanding if
>>> there
>>> was another way to do
it. I have now posted a suggestion #1790,
>>> so we
>>>
have a place holder for the desired functionality. http://www.amibroker.com/feedback/view_bug.php?bug_id=1790
>>>
>>>
Best regards,
>>> Dennis
>>>
>>> On Jun 29,
2009, at 9:19 AM, bruce1r wrote:
>>>
>>>> Dennis
-
>>>>
>>>> I was just making sure about you
understanding of the
>>>> SetBarsRequired() placement. I
agree with most of your summary,
>>>> but
>>>>
let's put the minor points aside and turn to your issue. FWIW,
I'd
>>>> like to have full control over bar requirements also.
Actually -
>>>> even more than you want, but that's another
story. Its something
>>>> that I and Fred and I have both
discussed with Tomasz some time
>>>> ago. I might even muse on
TJ's reasoning in his current design,
>>>>
but
>>>> he really should comment. But, we have to deal with the
hand that
>>>> we're
dealt.
>>>>
>>>> My impression is that you have an
"all in one" indicator that you
>>>> try to use as a control and
analysis center. I'll confess that
>>>> I've written one of these
also, but moved away from that type of
>>>> design for various
reasons. I think that we are at a point that if
>>>> you want to
explore some workarounds, we'll have to examine your
>>>>
requirements in detail, and this is probably best moved o ffline
to
>>>> e-mail.
>>>>
>>>> Before I
do that, I'll offer some comments that I hope might be of
>>>>
general interest about this general problem. Let's recap
your
>>>> statement about the design issue
-
>>>>
>>>> You said - "In my case, I sometimes
want to take a one shot pass at
>>>> allthe bars to gather some
statistics and save them, then
>>>> immediately dropback to some
minimum number of bars to speed up the
>>>> user interface for
changing parameters in the parameter window or
>>>> even working
with on-chart buttons, and go back to real time
>>>>
trading."
>>>>
>>>> So, given that as the problem
statement, some alternatives are -
>>>> Note that having say
SetBarsRequired(100,0), for example, DOES NOT
>>>> preclude
passing all of the data. I suspect that what you want is
>>>>
to
>>>> expand the back bars then call Equity() and gather stats.
A viable
>>>> alternative in some cases is just to
programatically zoom to the
>>>> full range, run and store the
stats,and programatically zoom back
>>>> to
>>>>
the original range. This preserves the 100 bars back
setting.
>>>> Another slightly more flexible alternative is to
run the backtestin
>>>> the AA. To do this, you shell out to a
JScript "controller"
>>>> program
>>>> which
invokes the appropriate AA backtest and stores the results.
>>>>
In your case, though, this might require the passing of many
>>>>
parameters in static variables, though. However, I use this
>>>>
technique for running a portfolio backtest over a dynamic
watchlist
>>>> on demand from an indicator. BTW, it seems to
"free up" the
>>>> indicator display, but I have only run this on
EOD data and can't
>>>> comment on how much parallelism can be
achieved on RT data. And, I
>>>> assume that TJ has the
appropriate lock-outs, but after about a
>>>>
year
>>>> and a half of use, no problems.
>>>> The
backtest "indicator" can be run in another document. This
>>>>
document can have a different, full data range. This has the
>>>>
advantage of only calculating when when visible, but I'd still
>>>> put a
>>>> trigger on it. But, again, some
parameter communication would be
>>>> needed.
>>>>
Each individual would have to decide on the trade-off's. #1 is
the
>>>> easiest. #2 might allow for some interesting things if
and when TJ
>>>> implements multi-processor support. There are
even a few other
>>>> alternatives. But this is probably enough
food for thought.
>>>>
>>>> --
BruceR
>>>>
>>>> --- In amibroker@xxxxxxxxxps.com,
Dennis Brown <see3d@>
wrote:
>>>>>
>>>>>
Bruce,
>>>>>
>>>>> Yes, I understand the SBR
requirements. My AFLs have it as the
>>>>>
last
>>>>> statement. The thing I was showing below was some
wishful thinking
>>>> if
>>>>> the way SBR
worked were modified to allow for reducing the
>>>>> number
of
>>>>> bars at each call. In fact it would be good to
iterate how it
>>>>> works
>>>>> here so
nobody gets confused by my
musings:
>>>>>
>>>>> When the indicator
chart is first run, it takes a pass just to
>>>>
figure
>>>>> out how man y bars are required (it also compiles
other
>>>> information to
>>>>> speed
executions). Each function, or loop may have a different
>>>>>
requirement for historical bars previous to the
FirstVisibleBar.
>>>> This
>>>>> first AFL pass
might give erroneous results since it does not know
>>>>>
until the end of the pass what all the requirements are, but I
>>>>> think
>>>>> it uses all bars, so that
should not cause a problem. It is a peak
>>>>> detecting
function, so that it only increased the number of bars
>>>>>
required, and never decreases them. If I have operations that
>>>>> write
>>>>> information to files or
static variables, I disable the writes
>>>>
during
>>>>> this pass since the ChartID is not valid
yet.
>>>>>
>>>>> Subsequent AFL passes now
know how many bars to load from the
>>>>
database
>>>>> to make sure that the visible bars show
accurate results.
>>>>>
>>>>> If some new
conditional AFL code executes during one of the
>>>>
subsequent
>>>> &g t; AFL passes, for instance an
AddToComposite() function that
>>>>
requires
>>>>> all bars, or an SetBarsRequired() function
with a larger number of
>>>>> bars, the next pass of AFL will
load more bars and this will be
>>>>>
the
>>>>> new minimum bars requirement. However, I have
noticed in my
>>>>> charts,
>>>>> that the
first pass after a new requirement may not use the
higher
>>>>> number of bars for an extra pass, so I am not
sure about the exact
>>>>> sequence. Perhaps, a new
requirement caused another "bar
>>>>> requirements" gathering
pass first. This can lead to errors if you
>>>>> are saving
results on a one shot basis in a static variable or
>>>>>
file.
>>>>>
>>>>> If an
SetBarsRequired() statement is found at the very end of
the
>>>> AFL,
>>>>> then it will override the
previous requirements. However, it still
>>>>> will not allow
you to reduce the requirements after the first
>>>>>
pass.
>>>>>
>>>>> I am not aware of any
detailed descriptions or flow charts of this
>>>>> execution
process for AFL, so all of this is just from
>>>>>
observations
>>>>> while debugging code, and might be
incorrect.
>>>>>
>>>>> I was musing about
giving the user AFL control over the reducing
>>>>>
the
>>>>> number of bars used on subsequent
passes.
>>>>>
>>>>> In my case, I sometimes
want to take a one shot pass at all the
>>>>>
bars
>>>>> to gather some statistics and save them, then
immediately drop
>>>> back to
>>>>> some
minimum number of bars to speed up the user interface
for
>>>>> changing parameters in the parameter window or even
working with
>>>>> on-
>>>>> chart buttons,
and go back to real time trading. It is a real drag
>>>>> when
I have to wait 5 seconds between every parameter change --
>>>>
which
>>>>> is the fastest I have been able to drop back to
from the 20 second
>>>>> full pass with SBR working in its
current operating mode. At 5
>>>>> seconds, a lot of the user
interface functions stop worki ng. It
>>>>
takes
>>>>> me quite a while to get my chart back to trading
fast after using
>>>> more
>>>>> bars for a
(not so) quick test.
>>>>>
>>>>> Of course,
once the user takes control of the number of bars
>>>>
required,
>>>>> it is his responsibility to monitor the
requirements carefully.
>>>>>
>>>>>
BR,
>>>>>
Dennis
>>>>>
>>>>>
>>>>>
On Jun 28, 2009, at 9:17 PM, bruce1r
wrote:
>>>>>
>>>>>> Dennis
-
>>>>>>
>>>>>> Close, but not quite.
If you were going to use SetBarsRequired()
>>>>
to
>>>>>> control the lookback, it is CRITICAL that it be
the LAST
>>>> statement in
>>>>>> the
program. If it is not, subsequent statements ( such as
>>>>>> HHV() )
>>>>>>
may
>>>>>> add to the requirement. If you want to see a
detailed
>>>> explanation of
>>>>>> this,
refer to Tomasz's QuickAFL article in the
KB.
>>>>>>
>>>>>> Regarding the issues
that you described in your previous
>>>> response
to
>>>>>> me,
>>>>>> there are a
couple of ways to deal with the issue that you are
>>>>>>
describing. When the teenagers go to bed and its quiet later,
>>>>>> I'll
>>>>>>
try
>>>>>> to outline
one.
>>>>>>
>>>>>> --
BruceR
>>>>>>
>>>>>> --- In amibroker@xxxxxxxxxps.com,
Dennis Brown see3d@
wrote:
>>>>>>>
>>>>>>> Yes
Tony,
>>>>>>>
>>>>>>> This is
close to what I was referring to as the array
solution,
>>>>>>> though
>>>>>>>
I would probably write it like this to make it
symmetrical:
>>>>>>>
>>>>>>>
minmax = LastValue( HHV( abs( m ), r )
);
>>>>>>>
>>>>>>> It would be
interesting if we could have a faster operation
>>>> such
that
>>>>>>> if we used a SetBarsRequired( r, 0 ) in the
preceding statement
>>>> to
>>>>>>>
reduce the range so the the range equaled the number of
bars
>>>>>>> specified, that the returned value would be
a single number of
>>>> the
>>>>>>>
result. Hmmmmm. If that mode were available, it would look
like
>>>>>>
this:
>>>>>>>
>>>>>>> m =
MACD();
>>>>>>>
>>>>>>> fb =
Status("FirstVisibleBar");
>>>>>>> lb =
Status("LastVisibleBar");
>>>>>>> r = lb -
fb;
>>>>>>>
>>>>>>>
SetBarsRequired( r, 0 )
>>>>>>> maximum = HHV( abs( m ),
r );
>>>>>>> Plot( m, "MACD", colorRed, styleOwnScale,
-maximum, maximum );
>>>>>>> Plot(0, "", colorBlack,
styleOwnScale, -maximum,
maximum);
>>>>>>>
>>>>>>> Just a
little
brainstorming.
>>>>>>>
>>>>>>>
BR,
>>>>>>>
Dennis
>>>>>>>
>>>>>>> On Jun
28, 2009, at 8:31 AM, Tony Grimes
wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
Try this solution, array
style:
>>>>>>>>
>>>>>>>> m
=
MACD();
>>>>>>>>
>>>>>>>>
fb = Status("FirstVisibl eBar");
>>>>>>>> lb =
Status("LastVisibleBar");
>>>>>>>> r = lb -
fb;
>>>>>>>>
>>>>>>>>
minimum = LastValue( LLV( m, r ) );
>>>>>>>> maximum
= LastValue( HHV( m, r )
);
>>>>>>>>
>>>>>>>> Plot(
m, "MACD", colorRed, styleOwnScale, minimum, maximum
);
>>>>>>>> Plot(0, "", colorBlack, styleOwnScale,
minimum,
maximum);
>>>>>>>>
>>>>>>>>
>>>>>>>>
On Sat, Jun 27, 2009 at 11:16 AM, Dennis Brown
see3d@
>>>>>>>>
wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
Maybe
not...
>>>>>>>>
>>>>>>>>
Through this discussion, the problem has been reduced to
>>>>
aligning
>>>>>> the
>>>>>>>>
min/max range of a MACD styleOwnScale plot to another zero
line
>>>>>>>> styleOwnScale plot statement.
Therefore, the only way to do
>>>> this
is
>>>>>>>> to find the min/max values of the MA CD
function in the
>>>> visible
bars
>>>>>>>> range and use those numbers in both
plot statements, or make
>>>>>>>>
the
>>>>>> MACD
>>>>>>>> range
symmetrical and then the zero line statement can be
any
>>>>>>>> symmetrical
range.
>>>>>>>>
>>>>>>>> I
am happy with my dual colored plot line at this point.
>>>>
However, to
>>>>>>>> complete the original idea, I
could use a simple loop to find
>>>>
the
>>>>>> min/
>>>>>>>> max
numbers of the MACD, but I am now wondering if there is
a
>>>>>> "faster"
>>>>>>>>
execution way using array logic
instead?
>>>>>>>>
>>>>>>>>
It seems like a waist of time to create an array of the Min/
>>>>
Max over
>>>>>>>> that range for all bars, then just
use the last value. I use
>>>>
loops
>>>>>>>> when I only want a single number
result related to the Min/Max
>>>>
value
>>>>>>>> over the last n bars only (like the v
isible bar range). Am I
>>>>
missing
>>>>>>>> an opportunity to approach this in a
more efficient
way?
>>>>>>>>
>>>>>>>>
BR,
>>>>>>>>
Dennis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
On Jun 27, 2009, at 9:06 AM, gmorlosky
wrote:
>>>>>>>>
>>>>>>>>>
maybe....
>>>>>>>>>
>>>>>>>>>
IF ( MACDline == Signalline) // histogram value equals
zero
>>>>>>>>> X =
lastvalue(MACDline-Signalline);
>>>>>>>>>
Plot (X,"",
colorblack);
>>>>>>>>>
>>>>>>>>>
--- In amibroker@xxxxxxxxxps.com,
Dennis Brown see3d@
wrote:
>>>>>>>>>>
>>>>>>>>>>
Yes, I have it set to 100%. The absolute values of the
>>>>
indicator
>>>>>>>>>>
will
>>>>>>>>>> vary wildly, depending on the
price and volatility of the
>>>>
stock.
>>>>>> I
>>>>>>>> &
gt;> plot ES, so the values are quite large at
times.
>>>>>>>>>>
>>>>>>>>>>
BR,
>>>>>>>>>>
Dennis
>>>>>>>>>>
>>>>>>>>>>
On Jun 26, 2009, at 5:58 PM, monitorit
wrote:
>>>>>>>>>>
>>>>>>>>>>>
If that's all you needed, the color change would be best.
>>>>
But, I
>>>>>>>>>>> think the solution I
suggested would work... you would still
>>>>>>
plot/
>>>>>>>>>>> see value very high or low
just within a section defined by
>>>>>>>>
pane*1/
>>>>>>>>>>> minvalue [at least it
has for me]. BTW, presently what is
>>>>>>>>>>>
the
>>>>>>>>
upper
>>>>>>>>>>> and lower bounds of the
MACD in relationship to the height
>>>>>>>>>>> of
>>>>>>
the
>>>>>>>>>>> pane? Is it 100% of the pane
height?
>>>>>>>>>>>
Dan
>>>>>>>>>>
;>
>>>>>>>>>>> --- In amibroker@xxxxxxxxxps.com,
Dennis Brown <see3d@>
>>>>
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
Dan,
>>>>>>>>>>>>
>>>>>>>>>>>>
This is what I usually do for indicators when I know the
>>>>
range
>>>>>>
of
>>>>>>>>>>>> values. However, MACD is
an unbounded indicator, so I don't
>>>>>>
know
>>>>>>>>>>>>
how
>>>>>>>>>>>> large the values are. It
is only the zero crossings and
>>>>>>
relative
>>>>>>>>>>>> peaks that are
useful info
here.
>>>>>>>>>>>>
>>>>>>>>>>>>
I just thought there would be some simple shortcut to
>>>>
actually
>>>>>>>>>>>> scanning the
visible bars for the min/max values to use in
>>>>
the
>>>>>>>>
plot
>>>>>>>>>>>> statemen ts. I think I
will just switch colors of the MACD
>>>>
from
>>>>>>>>
red
>>>>>>>>>>>>
to
>>>>>>>>>>>> green if it is above or
below zero instead of resorting to
>>>>
yet
>>>>>>>>>>>>
another
>>>>>>>>>>>>
loop.
>>>>>>>>>>>>
>>>>>>>>>>>>
Thanks,
>>>>>>>>>>>>
Dennis
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
On Jun 26, 2009, at 4:40 PM, monitorit
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
Dennis,
>>>>>>>>>>>>> Hi. You
might try this- Place a value in minvalue section
>>>>
but
>>>>>>>>>>>>>
none
>>>>>>>>>>>>> in maxvalue
section [I think maybe a value like 2 equates
>>>>
to
>>>>>>
1/2
>>>>>>>>>>>>> pan e height]
of your MACD and zero plot
statements.
>>>>>>>>>>>>>
Also,styleNoRescale in the zero plot statement. This
>>>>>>>>>>>>>
worked
>>>>>>
for
>>>>>>>>>>>>>
me
>>>>>>>>>>>>> when I wanted to
plot a histogram and a dot on the top of
>>>>
the
>>>>>>>>>>>>> histogram. Not
sure if it works with a line. If it
>>>>>>>>>>>>>
doesn't,
>>>>>>
you
>>>>>>>>>>>>> could try
plotohlc with H=max(0,my#) and
L=min(0,my#).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
--- In amibroker@xxxxxxxxxps.com,
Dennis Brown <see3d@>
>>>>
wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
This must be simple, but my AFL brain is fried today. I
>>>>
have
>>>>>>
an
>>>>>>>>>>>>>>
MACD
>>>>>>>>>>>>>> plot on
top of my main price chart, and I want to plot a
>>>>
zero
>>>>>>>>>>>>>>
line
>>>>>>>>>>>>>> over it.
It is plotted as StyleOwnScale of course. I
>>>>>>>>>>>>>>
can't
>>>>>>
use
>>>>>>>>>>>>>>
StyleLeftAxis because I am using it for something else.
I
>>>>>>>>>>>>>> guess
I
>>>>>>>>>>>>>> could do
something to figure out where the visible high
>>>>
and
>>>>>>
low
>>>>>>>>>>>>>>
values
>>>>>>>>>>>>>> of the
MACD are, but it seems like it should be easier
>>>>
than
>>>>>>>>
that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
TIA,
>>>>>>>>>>>>>>
Dennis
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
**** IMPORTANT PLEASE READ
****
>>>>>>>>>>>>> This group is
for the discussion between users
only.
>>>>>>>>>>>>> This is *NOT*
technical support
channel.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
TO GET TECHNICAL SUPPORT send an e-mail directly
to
>>>>>>>>>>>>> SUPPORT {at}
amibroker.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER
at
>>>>>>>>>>>>> http://www.amibroker.com/feedback/
>>>>>>>>>>>>>
(submissions sent via other channels won't be
considered)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
For NEW RELEASE ANNOUNCEMENTS and other news always
check
>>>>>>>>
DEVLOG:
>>>>>>>>>>>>> http://www.amibroker.com/devlog/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
Yahoo! Groups
Links
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
**** IMPORTANT PLEASE READ ****
>>>>>>>>>>>
This group is for the discussion between users only.
>>>>>>
;>>>>> This is *NOT* technical support
channel.
>>>>>>>>>>>
>>>>>>>>>>>
TO GET TECHNICAL SUPPORT send an e-mail directly
to
>>>>>>>>>>> SUPPORT {at}
amibroker.com
>>>>>>>>>>>
>>>>>>>>>>>
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER
at
>>>>>>>>>>> http://www.amibroker.com/feedback/
>>>>>>>>>>>
(submissions sent via other channels won't be
considered)
>>>>>>>>>>>
>>>>>>>>>>>
For NEW RELEASE ANNOUNCEMENTS and other news always
check
>>>>>>
DEVLOG:
>>>>>>>>>>> http://www.amibroker.com/devlog/
>>>>>>>>>>>
>>>>>>>>>>>
Yahoo! Groups
Links
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
&
gt;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
------------------------------------
>>>>>>>>>
>>>>>>>>>
**** IMPORTANT PLEASE READ ****
>>>>>>>>> This
group is for the discussion between users
only.
>>>>>>>>> This is *NOT* technical support
channel.
>>>>>>>>>
>>>>>>>>>
TO GET TECHNICAL SUPPORT send an e-mail directly
to
>>>>>>>>> SUPPORT {at}
amibroker.com
>>>>>>>>>
>>>>>>>>>
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER
at
>>>>>>>>> http://www.amibroker.com/feedback/
>>>>>>>>>
(submissions sent via other channels won't be
considered)
>>>>>>>>>
>>>>>>>>>
For NEW RELEASE ANNOUNCEMENTS and other news always check
>>>>
DEVLOG:
>>>>>>>>> http://www.amibroker.com/devlog/
>>>>>>>>>
>>>>>>>>>
Yahoo! Groups Links
>>>> & gt;
>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
------------------------------------
>>>>>>
>>>>>>
**** IMPORTANT PLEASE READ ****
>>>>>> This group is for
the discussion between users only.
>>>>>> This is *NOT*
technical support
channel.
>>>>>>
>>>>>> TO GET
TECHNICAL SUPPORT send an e-mail directly to
>>>>>> SUPPORT
{at} amibroker.com
>>>>>>
>>>>>> TO
SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
>>>>>> http://www.amibroker.com/feedback/
>>>>>>
(submissions sent via other channels won't be
considered)
>>>>>>
>>>>>> For NEW
RELEASE ANNOUNCEMENTS and other news always check
DEVLOG:
>>>>>> http://www.amibroker.com/devlog/
>>>>>>
>>>>>>
Yahoo! Groups Links
>>>>>>
>>>> & gt;
>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>
>
------------------------------------
>
> ****
IMPORTANT PLEASE READ ****
> This group is for the discussion between
users only.
> This is *NOT* technical support channel.
>
> TO
GET TECHNICAL SUPPORT send an e-mail directly to
> SUPPORT {at}
amibroker.com
>
> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER
at
> http://www.amibroker.com/feedback/
>
(submissions sent via other channels won't be considered)
>
> For
NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
>
Yahoo! Groups Links
>
>
>
