|
PureBytes Links
Trading Reference Links
|
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
<*> 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/
|