|
PureBytes Links
Trading Reference Links
|
Paul,
I think I understand what you are suggesting now. I am not so sure
that I could take advantage of that approach from the way my system is
architected, but I will let it percolate in my mind. I suppose I
could use the new static variable arrays to do the same thing in AFL
as far as not duplicating work every pass. I only do a little bit of
that now. I guess what I really wanted is to be able to keep the
plots on screen while changing params, and on-screen buttons. It
takes 5 seconds just to output already saved plots (in static arrays)
on each pass on a 200K bar backtest. I guess the other thing I could
do is compress my chart to a higher timescale (like 30 minutes) for
high density plots -- no wait, I don't have that ability in AFL to
directly change chart time scales yet. I will also have to look into
just splitting my work into two or three charts (as much as I hate
to). I overlap things like popup button arrays with the charting
areas to make efficient use of my screen real estate. This goes way
beyond, but does not diminish the value of a more flexible SBR. More
thought required on my part.
Thanks,
Dennis
On Jul 1, 2009, at 12:46 AM, Paul Ho wrote:
> Dennis
> Wouldn't dream of suggesting to you writing the whole lot in dll.
> You dont have a problem with the rest of your code, right? at least
> at far as I can follow.
> My comment is only related to the what you're trying to solve with a
> variable/flexible SBR. In other words, a dll function for
> marshalling of 200K bars, that function would check if work has been
> done already, if so, just return without further to do, if not,
> manage the 200k bars with what you need to do, allocate memory as I
> have outlined before. To do that should take only a fraction of a
> second if you can limit to a minimum of 200K bar arrays at 800Kb
> each. As to the rest of the code, you can easily leave it the way it
> is.
>
> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> 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@> 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/
|