|
PureBytes Links
Trading Reference Links
|
Hello,
If only AFL formula is written correctly and in optimum way
(i.e. using array processing only and not re-doing the same calculation
more than once), its speed is the same as compiled C/C++ code.
The overhead of AFL parsing is less than 0.1% when arrays are large
(like 100000 bars in your example)
Best regards,
Tomasz Janeczko
amibroker.com
Dennis Brown wrote:
> Hi Paul,
>
> Thanks for your comments. A 100 fold speed improvement in processing
> 100,000 bars for a backtest environment would indeed be nice.
> However, I doubt it could be made more than 10 times faster, which
> would still be nice. I hear what you are saying: just write my
> algorithms in C++ and forget about AFL for anything other than
> housekeeping. This may be a valid solution for a production system,
> or doing certain time consuming algorithms, but I did not buy
> Amibroker so that I could learn to code my systems in C++, I bought it
> so I could code them in a higher level array language. One
> development platform only please. (Besides, if I was going to write
> everything myself, I would throw away XP and do it all in OS X. I
> don't like MS software at all -- I only barely tolerate XP so I can
> run AB). My system is about 8500 lines of AFL source code. Less than
> half of that is my actual algorithms working on arrays. The rest is
> used to make AB into a systems development platform the way I like
> it. I only have one chart and one ticker that I use. I only run an
> indicator for trading. Each system has about 1000 parameters saved on
> disk. Having everything in readily available source for editing and
> running as an interpreter (AFL) makes it much easier for me to debug
> and maintain the system. It is still in development, (even though I
> am trading with it now), and it will probably be in development for
> years to come. Just because it is possible to write everything in C++
> does not mean that it is an excuse for not having good support for
> better low level functionality in AFL for able programmers. However,
> I do have some very specialized algorithms for processing geometry
> that would make sense to put into a DLL for speed purposes -- once I
> am happy with the prototype AFL code. I also have some different
> kinds of filters that could be turned into DLLs for speed. However,
> these would only improve speed by 10-20% at most. I don't calculate
> things more often than needed, but as you say I end up with a lot of
> arrays in the process of combining multiple systems into a single
> one. My needs are straight forward, but the thread has become a
> sounding board for different people that see things in a different
> light. It has made for a confusing jumble to try to follow, and
> should have been spawned into several more threads. My brain was
> fried when I started it, but I am fully recovered at this point. Oh
> well, thats life on the big board. LOL
>
> BR,
> Dennis
>
>
> On Jun 30, 2009, at 10:44 PM, Paul Ho wrote:
>
>
>> Dennis
>> The discussion seems to have shifted towards having AB allowing a
>> more flexible regime in SBR from some brain fried topics in order to
>> solve quite a specific situation that you have.
>> I think your problem can be solved right now if you looked at it
>> from a memory managment and performance perspective.
>> Lets take 200000 bars as an example, 200K bars of a single array is
>> 800K bytes, not very much. but a 100 of them will take 80M. it
>> starts to mount up. In afl, unless you are very careful, you will
>> easily doing a 100 array processings with a few lines here and
>> there. secondly, you only need to do it once, I dont know if it is
>> once a day, once in awhile..... but you dont do it very often.
>> AFL was designed so that users dont have to worry anything about
>> memory mangement, if an user wants the capability to manage the
>> resource being used for a specific situation. then dll is the
>> answer. In dll, you will have complete control how much and in what
>> way memory is allocated. I have done that sort of things many times,
>> you take over the allocation and dellocation memory yourself inside
>> your dll, by passing tomasz's memory allocation routine. As you are
>> writing code and allocating memory specific for your problem. You
>> can be a lot more economical than any general algorithm would. you
>> can build in controls that it is only executed when it is needed.
>> The results is a much faster and elagent solution, In all my
>> exprience, and I dont know how complex your stuff is, but from your
>> description, it doenst sound very complex, you should be able to get
>> the time down to a fraction of second for 200K bars.
>>
>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>>
>>> Brian,
>>>
>>> I believe that Tomasz is quite good at how he allocates and
>>> deallocates memory internally for arrays. Also if you are only
>>> talking about a few thousand bars, more time could be lost in trying
>>> to shuffle things around than just using all the bars. My minimum
>>> number of bars for a calculation is 7,000. That is just to get
>>> accurate real time trading signals. For backtesting, I use 200,000
>>> bars. When you are talking high bar counts, then being able to have
>>> control over the calculation size of the arrays can amount to some
>>> serious time savings.
>>>
>>> However, you are right in that if a large number of bars is only
>>> needed for an occasional calculation to generate some reference data,
>>> then it can be costly in time and space to make everything have to
>>> use
>>> all the bars. That is something that would take a programmer to
>>> recognize and be able to optimize.
>>>
>>> I look for cases where I can take advantage of these cases. So far,
>>> the only way to do this was to save the data to something like an ATC
>>> ticker and use foreign to access the data, or to run two different
>>> charts at different refresh rates and have them communicate their
>>> data
>>> via static variables.
>>>
>>> Trying to have AB figure out all this on the fly is complicated and
>>> beyond my understanding of how it could be done.
>>>
>>> BR,
>>> Dennis
>>>
>>>
>>> On Jun 30, 2009, at 9:38 AM, brian_z111 wrote:
>>>
>>>
>>>>> if RAM needs reorganizing, save the last 100 bars from the
>>>>> variables >etc calculated on 1000 bars e.g. static arrays etc, dump
>>>>> the rest >and then reload the new global SBR # bars i.e. 100.
>>>>>
>>>> What I meant to ask there was if it is possible to dump some data
>>>> out of RAM and keep a smaller amount that you will need
>>>> thereafter ... maybe move it around in RAM to to where it is needed
>>>> without the need to start again by dumping the lot and reading 100
>>>> bars in from the disc again.
>>>>
>>>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
>>>>
>>>>> Well, if my assumptions so far are more or less correct then that
>>>>> leads me towards another possibility ........
>>>>>
>>>>>
>>>>> ...... depending on how RAM memory works (not sure about that)
>>>>>
>>>>> - assuming a database of 5000 bars
>>>>>
>>>>> - if we need a large number of bars, say 1000, to calculate a long
>>>>> term indicator, or indicators ... if this was the largest bar
>>>>> requirement it could become the coded global SBR setting (I assume
>>>>> that this setting might make the need to load all bars for the
>>>>> first pass obsolete ... possibly polling all bars on the first pass
>>>>> has a function (check if bars are not null value, maybe?) ...
>>>>> assuming this function can be passed to the global SBR bars then
>>>>> putting the global SBR at the head of the code could drive AB to
>>>>> load only 1000 bars.
>>>>>
>>>>> - assuming that the 1000 bars are only need for a one off calc ...
>>>>> if we leave them all there will they restrict RAM availability for
>>>>> other uses (as I said I am not sure if contiguous memory on the
>>>>> disc translates into contiguous memory in RAM) ... if there is any
>>>>> RAM advantage to be gained then a second global SBR command, set
>>>>> to, say 100 bars, that comes after the block of code that needed
>>>>> 1000 bars, could trigger off a dump of the 900 bars no longer need
>>>>> OR of RAM needs reorganizing, save the last 100 bars from the
>>>>> variables etc calculated on 1000 bars e.g. static arrays etc, dump
>>>>> the rest and then reload the new global SBR # bars i.e. 100.
>>>>>
>>>>> Blocks of code that only need < 100 bars could then be controlled
>>>>> via local SBR settings (one for each block).
>>>>>
>>>>>
>>>>> Beyond that idea #3 keeps coming back to me.......
>>>>>
>>>>> i.e. that AB could, should, would poll the CPU for availability and
>>>>> prioritize processing tasks.
>>>>>
>>>>> Some kind of flow control for the order of execution could be a
>>>>> tiny step in that direction i.e. reprocessing of a block of code,
>>>>> with a large number of bars, might be set to low priority (if you
>>>>> only need the answer every now and then) and AB would feed it to
>>>>> the processor a bit at a time (when the processor is not busy on
>>>>> your hot short term code).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
>>>>>
>>>>>> 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@xxxxxxxxxxxxxxx, "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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> **** 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
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> **** 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
<*> 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/
|