|
PureBytes Links
Trading Reference Links
|
Brian,
Herman's explanations in the "Speeding up code ???" thread explain it
better than I could.
BR,
Dennis
On Jul 3, 2009, at 1:30 AM, brian_z111 wrote:
> Dennis,
>
> I really did expect you to be asleep at this time of my day.
>
>> If you are only working on 100 or 1000 bars, none of this matters
>> etc
>
> Understood .... I just used that as the easily remembered example
> that I have been using.
>
>> It is only when you have many thousands of bars and
>> a complex formula that on some passes uses tens of thousands of
>> >bars and most other passes only needs a few thousand bars that
>> you >need to worry about optimizing the number of bars. It is
>> just all >about the time it takes to execute each operation.
>
> That is what I am asking ... is is faster to perform process1, on
> many thousands of bars, and process2 on a few thousand bars,
> simultaneously
>
> OR process1, on many thousands of bars
>
> and then (SBR) reload a few thousand bars to perform process2?
>
> The direction of your suggestion suggests that the latter is the
> fastest option so therefore:
>
> - the time taken to changeover SBR and reload the data is negligible
> (or will be if it doesn't restart the charts)
>
> SO,
>
> - there must be a significant timesaving as a result of performing
> the same operation on a few1000 bars of a few1000 bar array compared
> to performing it on few1000 bars of a many thousand bar array.
>
> Does that mean that the bars in memory, that are being carried, are
> a drag on the system in some way OR are they being silently
> processed, in some way, even though we referenced only a portion of
> them?
>
> (I don't necessarily expect you, or anyone to answer my 'thinking
> outloud' but is nice if you, or someone does).
>
>> I need this. You probably don't -- but I don't know for sure about
>> your needs.
>
> I am not using megabars at the moment but I am interested to learn
> about AB's philosophy and programming philosphy .... If I can learn
> and retain the best ideas I am in a good position for the future.
>
> I might need it in future or I might be in the position to help a
> newcomer in the forum (new programming guys and girls like to get
> off to a flying start with this type of stuff).
>
> I am keeping up the pin-pricking discussion because sometimes it
> leads to some good spinoffs to go with the original suggestion or,
> at the least, helps promote the idea to other users.
>
>
> At the moment my programming task is to do some more with the code
> that I got so far with way back at the System Performance Indicator
> discussion.
>
> I posted some array code for paired trading but the signal I used
> for the example was pretty crappy.
> I had trouble then with finding a way to:
>
> - incorporate stops etc
> - get multiple signals, using array processing
>
> A solution seems to be appearing so I am having another go ... it
> leads up to producing an array of ALL the trading signals rather
> than being limited to only one signal at a time (as per AB's default).
>
> If I get it working then I have the basis for sending trade series
> to R Math, for some custom applications (MoneyManagement etc) or
> maybe doing it here.
>
> I don't push the programming development hard, mainly because I have
> a mile of interesting research going on to extend RalphVinces work
> into some slightly new areas or to add detail to it ... that takes
> up my free time completely.
>
> Yes, I am very much looking forward to Howard's next book.
>
> Thanks for your help and your answers ... I do appreciate it and I
> now know a little bit about a subject that I knew nothing about when
> the conversation started.
>
> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>>
>> Brian,
>>
>> If you are only working on 100 or 1000 bars, none of this matters as
>> far as I am concerned. Just use all the bars in an array operation,
>> or use fewer bars in a loop if it can not be done with array
>> operations. Let QuickAFL do its thing and everything runs fast under
>> those conditions. It is only when you have many thousands of bars
>> and
>> a complex formula that on some passes uses tens of thousands of bars
>> and most other passes only needs a few thousand bars that you need to
>> worry about optimizing the number of bars. It is just all about the
>> time it takes to execute each operation. I would rather wait for a
>> much faster computer clock speed next year than do all this speed
>> optimizing with more complex code. However, clock speeds are no
>> longer advancing much because of the exponential power and heat
>> generated. Instead, CPU chip design has changed to increasing the
>> number of cores. That does not help a single threaded process, so I
>> am forced to figure other ways I can make the program faster. I need
>> this. You probably don't -- but I don't know for sure about your
>> needs.
>>
>> There is one essential component to learn how to trade -- practice,
>> practice, practice. There is also the same essential component to
>> learn how to program... otherwise the lightbulb does not go on.
>>
>> Programming AFL is the best way to learn AFL. So, I am in agreement
>> with you on that. However, there are better teaching aids for just
>> about any other general purpose language. Luckily we have people
>> like
>> Howard Bandy writing books to help make learning AFL easier.
>>
>> BR,
>> Dennis
>>
>> On Jul 2, 2009, at 6:04 PM, brian_z111 wrote:
>>
>>> Dennis
>>>
>>>> However, I do appreciate it when you edit your self admitted
>>>>> rambling posts to a more concise level before hitting send. I
>>>>> sometimes find it hard to identify the main point or real as
>>>> opposed >to rhetorical questions so that I can easily make a
>>>> meaningful >response without having to read it over 2 or 3 times
>>>> to figure it >out. Sometimes, if I can't get it on the first
>>>> read, I simply >ignore it and move one (if it is not in my
>>>> thread).
>>>
>>> Apologies for the 'air swings' ... I am striving to understand
>>> something I know very little about, and do it in an AB context,
>>> without having to go and learn programming or computing in general.
>>>
>>> I have one or two gross misconceptions in this area that I am trying
>>> to sort out.
>>>
>>> I don't place as much priority on 'keeping it all in a neat pile' as
>>> many others do.
>>>
>>> One thing I was trying to get at:
>>>
>>> If you are using SBR1000 and want to work on, say, 100 bars only,
>>> isn't it easy enough to just reference 100 bars without changing the
>>> SBR (and hence 'restarting' the charts).
>>>
>>> If you could change, from SBR1000 to SBR100, without 'rstarting the
>>> charts' what advantage does that offer to just referencing the 100
>>> bars in the first place?
>>>
>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
>>>>
>>>> Brian,
>>>>
>>>> Sorry if you took my impersonal remarks as personally directed
>>>> towards
>>>> you. I will generally direct personal remarks to a particular
>>>> person.
>>>> My frustration was not with anyones posts, but with myself for not
>>>> splitting off a new thread with an appropriate subject header for
>>>> the
>>>> valuable content unrelated to MACD plots.
>>>> And yes, I needed to get some sleep.
>>>>
>>>> My AB Development item was as a response to posts on this
>>>> thread. I
>>>> realize that just talking about needs on the forum does not
>>>> generate
>>>> an AB solution without submitting the item to the development
>>>> suggestion list. My announcement of that item is an invitation to
>>>> respond to it in the development list page, where hopefully enough
>>>> interest will increase the likelihood of fulfillment.
>>>>
>>>> However, I do appreciate it when you edit your self admitted
>>>> rambling
>>>> posts to a more concise level before hitting send. I sometimes
>>>> find
>>>> it hard to identify the main point or real as opposed to rhetorical
>>>> questions so that I can easily make a meaningful response without
>>>> having to read it over 2 or 3 times to figure it out. Sometimes,
>>>> if I
>>>> can't get it on the first read, I simply ignore it and move one (if
>>>> it
>>>> is not in my thread). I have a tendency to be a bit verbose myself
>>>> in
>>>> my posts, and do a lot of editing -- as if anyone could tell. LOL
>>>>
>>>> Your points below are concise and appreciated.
>>>>
>>>> Best regards,
>>>> Dennis
>>>>
>>>>
>>>> On Jul 1, 2009, at 5:57 AM, brian_z111 wrote:
>>>>
>>>>>> My needs are straight forward, but the thread has become a
>>>>>> sounding board for different people that see things in a
>>>>>> different
>>>>>> light.
>>>>>
>>>>> If you are just posting to tell someone, anyone, everyone, about
>>>>> your needs go straight to the feedback centre.
>>>>> You don't need the impramatur of anyone else to file a suggestion.
>>>>>
>>>>> Since you chose to post an item from your AB development list here
>>>>> then you made the choice to use the forum as a sounding board for
>>>>> your needs.
>>>>>
>>>>>
>>>>>> It has made for a confusing jumble to try to follow, and
>>>>>> should have been spawned into several more threads.
>>>>>
>>>>> I am disappointed that you didn't see any relationship between the
>>>>> various posts .... it all looks like part of the same discussion
>>>>> to
>>>>> me (except for MACD plots).... I thought you were smart and that
>>>>> you
>>>>> could keep up .... who started to discuss your programming needs
>>>>> in
>>>>> the middle of a Plot discussion anyway?
>>>>>
>>>>> If you want to hear back only what you want to hear back go and
>>>>> shout your needs into the Grand Canyon.
>>>>>
>>>>> You really didn't nail your point until you said:
>>>>>
>>>>> "With a loop, I have total control of how many bars to process,
>>>>> and fewer is faster. I would also like to have that same explicit
>>>>> control over how many bars the built-in array operations use,
>>>>> because
>>>>> they will also operate faster with fewer bars, and are more
>>>>> efficient
>>>>> than loops doing the same operations."
>>>>>
>>>>> If the AB manual contained accurate info, on its processes, as it
>>>>> should, then I would be able to respond to your discussion on your
>>>>> needs without all of the questioning and casting around looking
>>>>> for
>>>>> some solid ground.
>>>>>
>>>>> BTW your request for a 'flexible' SBR is one of the things I
>>>>> discussed in the past in one of my long, rambling dissertations on
>>>>> array processing (array matrices and arrays of arrays) ... which
>>>>> BTW
>>>>> no one new anything about ....you are just asking Tomasz to give
>>>>> you
>>>>> a function to reference a specific subset of the array
>>>>> elements ...
>>>>> like when I talked about:
>>>>>
>>>>> variable[990-1000];//reference the last 10 elements of a 1000 bar
>>>>> array.
>>>>>
>>>>> Why confine it to only the last, x number of elements?
>>>>>
>>>>>
>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> 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
>>>
>>>
>>>
>>
>
>
>
>
> ------------------------------------
>
> **** 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/
|