In that case ...
- if
load/execute;
load/execute;
load/execute;
is the efficient model?
- why is
(load1000/execute10 00)process1;
(load1000/execute10 00)process2;
(load1000/execute10 00)process3;
more efficient than
(load1000/execute10 00)process1;
(load1000/execute10 0)process2;
(load1000/execute10 00)process3;
I just got out of bed ... haven't even had breakfast yet!
--- In amibroker@xxxxxxxxx ps.com, Dennis Brown <see3d@xxx> wrote:
>
> Brian,
>
> You are making things to complicated.
>
> The execution model as I understand it for AB is that only static
> variables, a few other housekeeping items, and the "compiled" formula
> are retained in memory between passes. The operating system itself
> has a lot of information saved about windows and processes also.
>
> AB processes one chart, say for IBM, then, it process the next chart
> for say AAPL, and so on for perhaps 20 charts that you have open in
> your desktop. That may take 10 times more memory than your machine
> has available. By reloading the data for each chart from disk, or
> cache, or whatever, the resources of the machine can be shared more
> effectively, and the program architecture is simpler and less prone to
> bugs.
>
> However, I use fewer bars than loaded in RAM all the time using
> loops. 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.
>
> When we start talking about multiple core and multiple charts being
> calculated in parallel, then more memory will be required based on the
> number of parallel processes and processors. Tomasz has already said
> he is going to make this happen when the stars are in proper
> alignment. I am sure it will be as efficient as Tomasz can make it.
>
> Get some sleep. ;-)
>
> BR,
> Dennis
>
>
>
> On Jun 30, 2009, at 8:37 PM, brian_z111 wrote:
>
> > Rather than find and 'bump up' two older posts I will add some
> > additional comment here.
> >
> > Re proactive polling and managing of processing capability by AB:
> >
> > - this idea keeps coming back to me
> > - I am tentatively discussing it on the basis that we are all
> > professionals or aspiring professionals and therefore we all have at
> > least one dedicated trading machine OR we are FundManagers etc and
> > have an IT dept that looks after our IT needs .... therefore we are
> > all in the position to elect the option for AB to take over our
> > machine (at least I am) ..... I would like AB to do this ... to
> > efficiently manage the allocation of my processing time (biased
> > towards its own ends)
> > - perhaps this could become a feature of the Pro version and make it
> > really distinctive from the Standard version
> >
> >
> > Re memory allocation:
> >
> > - what I am questioning here is the way AB uses the cache and RAM in
> > particular .... compared to other programs etc ... what does it do
> > differently and is that absolutely essential to its performance
> >
> > - so AB parses the formula, makes a smart decision about the least #
> > bars required and then loads that number of bars into memory (from
> > the cache?)
> >
> > - once this optimum allocation (of array length and hence memory)
> > has been made and the data is loaded into memory can we have a
> > second bite of the cherry ... if we now want to work on a lesser
> > number of bars can we handle that new objective IN MEMORY or not ...
> > if so can we do that efficiently (without corrupting data or without
> > taking longer to do it than it would to dump the original allocation
> > and just reload the new requirement from the cache?)
> >
> > - if it is more efficient to dump the loaded data and reload from
> > cache (AB's default behaviour seems to imply this) then what happens
> > when a new bar arrives
> >
> > for example:
> >
> > - we have SBR 1000
> > - this is loaded into memory
> > - the formula is executed
> > - a new bar arrives .....
> >
> >
> > ..... what happens now?
> >
> > - we have 1000 + 1 bars 'in memory' or trying to get in there? ...
> > we have exceeded, or are about to exceed our memory allocation?
> >
> > - if processors in general (or specifically AB) can't handle this
> > internally then they must have to 'write' the new bar into the cache
> > then reload the current 1000 bars into memory and do all the calcs
> > again
> >
> > OR
> >
> > - if processors in general (or specifically AB) can handle this
> > internally then they must efficiently rearrange the data in memory
> > in some way ... perhaps they kick the oldest bar out of one side of
> > the bed and let the new bar into the other.
> >
> >
> > Of course the most interesting question so far, in my mind, is can
> > processors in general (and specifically AB) run calcs on some arrays
> > in allocated memory and then efficiently change over to running
> > calcs on only a portion of the arrays ... or is any attempt to do
> > this within the processor so inefficient that reload from cache/
> > rebooting the execution is actually the best way to do it?
> >
> >
> >
> >
> > --- In amibroker@xxxxxxxxx ps.com, "brian_z111" <brian_z111@ > wrote:
> >>
> >>> I'd suggest that we let Tomasz worry about the "how".
> >>
> >> I am conflicted about this.
> >>
> >> On the one hand I am innately driven by the desire to know how it
> >> works, at a basic level, and to fix something that is broken if it
> >> can be fixed.
> >>
> >> I have to try to balance my own needs against the needs of others,
> >> including Tomasz.... it is a question of how far will I push it, to
> >> try to glean some little piece of information from somewhere, or to
> >> give Tomasz a heads up about the issues I am facing on my side of
> >> the screen. I understand there is a risk that I will be perceived
> >> as being too cheeky or making personal attacks on Tomasz .. so be it.
> >>
> >> This is how I make my living and I have invested a lot of time into
> >> learning AB ... time that I can't get back ... I can't afford to
> >> make friends or take prisoners in this business ... I have to
> >> know ... the consequences are too high for me to live on good
> >> guesses for ever.
> >>
> >> Frankly I have a love hate relationship with AB.
> >>
> >> I can't fix my car if I don't know how it works.
> >>
> >> Is there any car sold in America that comes without a 100% detailed
> >> maintenance manual ... would any manufacturer be allowed to sell
> >> the vehicle without providing a 100% detailed maintenance manual?
> >>
> >> In the absence of the facts I have guessed my way to many a good
> >> understanding ... guess by guess until I get there.
> >>
> >> I reserve the right at all times to continue to use this method ...
> >> I would much rather know for sure though. Of course, I could do my
> >> guessing in private but then anyone in the forum who is interested
> >> would miss out on the value of my occasional good guess.
> >>
> >> <snip>When editing/developing an AFL that is inserted on a
> >> chart, any change causes an execution using all bars. This can be
> >> painful very painful when you have 100k+ bars and complex code. I
> >> understand why AB needs to do this, but there is a "chicken and egg"
> >> problem of needing to execute the AFL on all bars in order to get the
> >> SetBarsRequired( ) requirements. <snip>
> >>
> >> This is the part that has me confused .... Dennis also speculated
> >> that AB uses 'all bars', at the first pass, to calculate SBR.
> >>
> >> I went back to the KB, yesterday, and reread the article on
> >> QuickAFL and it definitely says that AB calculates forward and
> >> backward bar requirements when PARSING the formula .... my limited
> >> understanding is that AB has its own compiler (written by Tomasz)
> >> and so this is done by the AB compiler before the code is executed
> >> on even a bar of data?
> >>
> >> So, I don't think rote execution of all SetBars, after edit, is
> >> being driven by SBR or QuickAFL ... IMO it is being driven by AB's
> >> core behaviour of autoallocating memory and block (orthoganal)
> >> treatment of arrays of the same length ... that is what I am trying
> >> to flag ... this is AB's 'strength' when BT or Opt large databases
> >> etc.
> >>
> >> Does this strength become a weakness in RT charts and if so can we
> >> OR AB do anything about it.
> >>
> >> So far, based on Tomasz's last comments the answer is no .. he said
> >> the penalty of this default behaviour, when charts need to be
> >> recalced as new bars arrive etc, is less than the penalty involved
> >> in managing 1 new bar at a time (I am keeping an open mind on this
> >> until I find out for certain one way or another ... and it seems as
> >> if that might take until eternity).
> >>
> >> My best andidote so far appears to be to brutally simplify my RT
> >> needs (careful design and selection of indicators, work to reduce
> >> the number of lookback bars required, re-engineer the maths to
> >> report more info in less bars and careful design selection of
> >> metrics etc).
> >>
> >>> 2. In the AA, Tomasz implemented almost all that is needed.
> >>
> >> I could strongly disagree with that statement on several counts.
> >>
> >> <snip>The only thing that is a slight drawback is that if you run
> >> an Explore or Scan on a CURRENT SYMBOL on an unchanged AFL, it
> >> doesn't use the SetBarsReuiqed( ) from the previous execution. It
> >> does use the
> >> requirement, though, on tickers 2-N when it is run on a watchlist.
> >> SO,I consider this a minor annoyance, and am guessing that TJ had
> >> to do this for structural reasons.<snip>
> >>
> >> It would take forever for Tomasz to explain why he does everything
> >> he does ..... it is essential for users to know what AB is doing
> >> though ..... how it does it is also nice to know.
> >>
> >> Thanks for sharing this info ... I will add it to my hardcopy file
> >> of "The Golden Precepts of AmiBroker".
> >>
> >> --- In amibroker@xxxxxxxxx ps.com, "bruce1r" <brucer@> wrote:
> >>>
> >>> Dennis, Brian, all -
> >>>
> >>> I'd suggest that we let Tomasz worry about the "how". What I think
> >>> Tomasz does a masterful job of is "integrating" requests and
> >>> requirements within his desired business model. And finally
> >>> consider
> >>> this - even the best programmer can make educated guesses about
> >>> another's code, but only the author knows what is truly possible and
> >>> most efficient.
> >>>
> >>> With that in mind, I will mention two things though that are
> >>> possible
> >>> "opportunities" , and I'll mention them here only to stimulate
> >>> thought on
> >>> others that might have been overlooked or might be desirable. My
> >>> personal inclination is to code around issues and get on with
> >>> using the
> >>> app and/or trading. But -
> >>>
> >>> 1. Long history of high frequency bars such as 1-min bars
> >>> create some
> >>> special problems. When editing/developing an AFL that is inserted
> >>> on a
> >>> chart, any change causes an execution using all bars. This can be
> >>> painful very painful when you have 100k+ bars and complex code. I
> >>> understand why AB needs to do this, but there is a "chicken and egg"
> >>> problem of needing to execute the AFL on all bars in order to get
> >>> the
> >>> SetBarsRequired( ) requirements. Something should be done about this
> >>> long term because it makes debugging / development painful. I
> >>> just code
> >>> around it by detecting the all bar condition and bypassing
> >>> calculations
> >>> except for a SetBarsRequired( ). I can then click to test with the
> >>> smaller number of bars.
> >>> 2. In the AA, Tomasz implemented almost all that is needed.
> >>> The only
> >>> thing that is a slight drawback is that if you run an Explore or
> >>> Scan on
> >>> a CURRENT SYMBOL on an unchanged AFL, it doesn't use the
> >>> SetBarsReuiqed( ) from the previous execution. It does use the
> >>> requirement, though, on tickers 2-N when it is run on a
> >>> watchlist. SO,
> >>> I consider this a minor annoyance, and am guessing that TJ had to do
> >>> this for structural reasons.
> >>> -- BruceR
> >>>
> >>>
> >>>
> >>>
> >>> --- In amibroker@xxxxxxxxx ps.com, 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@xxxxxxxxx ps.com, "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@xxxxxxxxx ps.com, 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@xxxxxxxxx ps.com, "brian_z111" <brian_z111@ >
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>> I still have a few questions about this.
> >>>>>>>>>
> >>>>>>>>> FTR:
> >>>>>>>>>
> >>>>>>>>> I am OK with the idea so far ... I am wondering about the
> >>>>>>>>> practicality of the implementation though... I guess you guys
> >>>>>>>>> (Fred,Bruce, Dennis), being programmers, are confident you are
> >>>>>>>>> going
> >>>>>>>>> to gain time, either when running long BT's or Opts OR only in
> >>> RT
> >>>>>>>>> charts?
> >>>>>>>>>
> >>>>>>>>> Does anyone have any idea where these gains would come from,
> >>>>>>>>> or
> >>>>>>>>> how
> >>>>>>>>> they could be achieved, in processing terms .... what sort of
> >>> time
> >>>>>>>>> gains can we expect if Tomasz does decide to action the idea?
> >>>>>>>>>
> >>>>>>>>> When Dennis said that calling SBR with a lower # bars RESTARTS
> >>> the
> >>>>>>>>> charts I am guessing that he means bars are reloaded into
> >>> memory,
> >>>>>>>>> thus rebuilding the charts.... is this the default behaviour?
> >>>>>>>>>
> >>>>>>>>> .. if so this would be the default for any change of setting
> >>>>>>>>> (either up or down) so any change of setting has this
> >>>>>>>>> 'penalty'
> >>>>>>>>> attached?
> >>>>>>>>>
> >>>>>>>>> Are you guys suggesting that, where two or more calls are made
> >>> to
> >>>>>>>>> SBR() that AB could still estimate max bars required for the
> >>>>>>>>> longest SBR after the first pass, keep them in memory, but
> >>>>>>>>> only
> >>>>>>>>> access the number required for each subsequent block of
> >>>>>>>>> shorter
> >>>>>>>>> length arrays .... i.e. where there are more than one SBR in a
> >>>>>>>>> formula, the longest SBR will be the primary SBR, and control
> >>>>>>>>> the #
> >>>>>>>>> bars loaded, while the secondary SBR's set how many of the
> >>> loaded
> >>>>>>>>> bars to actually use?
> >>>>>>>>>
> >>>>>>>>> I don't know if instructing AB to change to using, say, 10
> >>>>>>>>> bars,
> >>>>>>>>> from a loaded memory of, say, 100, has much of a time penalty
> >>>>>>>>> attached to it ... I guess not?
> >>>>>>>>>
> >>>>>>>>> I don't understand how processors work so I am not certain
> >>>>>>>>> that
> >>>>>>>>> this would lead to a time gains ... I guess if there are gains
> >>> to
> >>>>>>>>> be had, by this method, it would depend on how long it takes
> >>>>>>>>> to
> >>>>>>>>> change the no bars actually processed and ... how many lines
> >>>>>>>>> of
> >>>>>>>>> code are included in the short array block.
> >>>>>>>>>
> >>>>>>>>> I assume that processing 10 bars, already in memory, is
> >>>>>>>>> actually
> >>>>>>>>> faster than processing the whole 100, already in memory ....
> >>> that
> >>>>>>>>> is a big assumption on my part (could be wrong!).
> >>>>>>>>>
> >>>>>>>>> Is that what you guys are suggesting or is it something else?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --- In amibroker@xxxxxxxxx ps.com, Dennis Brown <see3d@> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Bruce,
> >>>>>>>>>>
> >>>>>>>>>> Thanks for your suggestions. They are appreciated. I will
> >>>>>>>>>> contact
> >>>>>>>>>> you off-line for further discussion about these.
> >>>>>>>>>>
> >>>>>>>>>> I am glad to see that I am not the only one who would like to
> >>>>>>>>>> have
> >>>>>>>>>> more control over the number of bars used in AFL. I posted
> >>>>>>>>>> one
> >>>>>>>>>> bug
> >>>>>>>>>> related to these long ago, and commented on the one way
> >>>>>>>>>> nature
> >>> of
> >>>>>>>>>> SBR,
> >>>>>>>>>> but never posted my own suggestion for having the ability to
> >>>>>>>>>> reduce
> >>>>>>>>>> the number of bars via SBR, because I previously could not
> >>>>>>>>>> get
> >>>>>>>>>> any
> >>>>>>>>>> responses from this forum or support about how I should go
> >>> about
> >>>>>>>>>> trying to do this. I did not want to suggest something
> >>>>>>>>>> without
> >>>>>>>>>> knowing it was desired by more than myself, or
> >>>>>>>>>> understanding if
> >>>>>>>>>> there
> >>>>>>>>>> was another way to do it. I have now posted a suggestion
> >>> #1790,
> >>>>>>>>>> so we
> >>>>>>>>>> have a place holder for the desired functionality.
> >>> http://www.amibroke r.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@xxxxxxxxx ps.com, Dennis Brown <see3d@>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Bruce,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes, I understand the SBR requirements. My AFLs have it as
> >>> the
> >>>>>>>>>>>> last
> >>>>>>>>>>>> statement. The thing I was showing below was some wishful
> >>>>>>>>>>>> thinking
> >>>>>>>>>>> if
> >>>>>>>>>>>> the way SBR worked were modified to allow for reducing the
> >>>>>>>>>>>> number of
> >>>>>>>>>>>> bars at each call. In fact it would be good to iterate
> >>>>>>>>>>>> how it
> >>>>>>>>>>>> works
> >>>>>>>>>>>> here so nobody gets confused by my musings:
> >>>>>>>>>>>>
> >>>>>>>>>>>> When the indicator chart is first run, it takes a pass just
> >>> to
> >>>>>>>>>>> figure
> >>>>>>>>>>>> out how man y bars are required (it also compiles other
> >>>>>>>>>>> information to
> >>>>>>>>>>>> speed executions). Each function, or loop may have a
> >>> different
> >>>>>>>>>>>> requirement for historical bars previous to the
> >>>>>>>>>>>> FirstVisibleBar.
> >>>>>>>>>>> This
> >>>>>>>>>>>> first AFL pass might give erroneous results since it does
> >>>>>>>>>>>> not
> >>>>>>>>>>>> know
> >>>>>>>>>>>> until the end of the pass what all the requirements are,
> >>>>>>>>>>>> but
> >>> I
> >>>>>>>>>>>> think
> >>>>>>>>>>>> it uses all bars, so that should not cause a problem. It
> >>>>>>>>>>>> is a
> >>>>>>>>>>>> peak
> >>>>>>>>>>>> detecting function, so that it only increased the number of
> >>>>>>>>>>>> bars
> >>>>>>>>>>>> required, and never decreases them. If I have operations
> >>>>>>>>>>>> that
> >>>>>>>>>>>> write
> >>>>>>>>>>>> information to files or static variables, I disable the
> >>> writes
> >>>>>>>>>>> during
> >>>>>>>>>>>> this pass since the ChartID is not valid yet.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Subsequent AFL passes now know how many bars to load from
> >>>>>>>>>>>> the
> >>>>>>>>>>> database
> >>>>>>>>>>>> to make sure that the visible bars show accurate results.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If some new conditional AFL code executes during one of the
> >>>>>>>>>>> subsequent
> >>>>>>>>>>> &g t; AFL passes, for instance an AddToComposite( ) function
> >>> that
> >>>>>>>>>>> requires
> >>>>>>>>>>>> all bars, or an SetBarsRequired( ) function with a larger
> >>>>>>>>>>>> number of
> >>>>>>>>>>>> bars, the next pass of AFL will load more bars and this
> >>>>>>>>>>>> will
> >>> be
> >>>>>>>>>>>> the
> >>>>>>>>>>>> new minimum bars requirement. However, I have noticed in my
> >>>>>>>>>>>> charts,
> >>>>>>>>>>>> that the first pass after a new requirement may not use the
> >>>>>>>>>>>> higher
> >>>>>>>>>>>> number of bars for an extra pass, so I am not sure about
> >>>>>>>>>>>> the
> >>>>>>>>>>>> exact
> >>>>>>>>>>>> sequence. Perhaps, a new requirement caused another "bar
> >>>>>>>>>>>> requirements" gathering pass first. This can lead to errors
> >>>>>>>>>>>> if you
> >>>>>>>>>>>> are saving results on a one shot basis in a static variable
> >>> or
> >>>>>>>>>>>> file.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If an SetBarsRequired( ) statement is found at the very
> >>>>>>>>>>>> end of
> >>>>>>>>>>>> the
> >>>>>>>>>>> AFL,
> >>>>>>>>>>>> then it will override the previous requirements. However,
> >>>>>>>>>>>> it
> >>>>>>>>>>>> still
> >>>>>>>>>>>> will not allow you to reduce the requirements after the
> >>>>>>>>>>>> first
> >>>>>>>>>>>> pass.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am not aware of any detailed descriptions or flow
> >>>>>>>>>>>> charts of
> >>>>>>>>>>>> this
> >>>>>>>>>>>> execution process for AFL, so all of this is just from
> >>>>>>>>>>>> observations
> >>>>>>>>>>>> while debugging code, and might be incorrect.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was musing about giving the user AFL control over the
> >>>>>>>>>>>> reducing
> >>>>>>>>>>>> the
> >>>>>>>>>>>> number of bars used on subsequent passes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In my case, I sometimes want to take a one shot pass at all
> >>> the
> >>>>>>>>>>>> bars
> >>>>>>>>>>>> to gather some statistics and save them, then immediately
> >>> drop
> >>>>>>>>>>> back to
> >>>>>>>>>>>> some minimum number of bars to speed up the user interface
> >>> for
> >>>>>>>>>>>> changing parameters in the parameter window or even working
> >>>>>>>>>>>> with
> >>>>>>>>>>>> on-
> >>>>>>>>>>>> chart buttons, and go back to real time trading. It is a
> >>>>>>>>>>>> real
> >>>>>>>>>>>> drag
> >>>>>>>>>>>> when I have to wait 5 seconds between every parameter
> >>>>>>>>>>>> change
> >>> --
> >>>>>>>>>>> which
> >>>>>>>>>>>> is the fastest I have been able to drop back to from the 20
> >>>>>>>>>>>> second
> >>>>>>>>>>>> full pass with SBR working in its current operating mode.
> >>>>>>>>>>>> At
> >>> 5
> >>>>>>>>>>>> seconds, a lot of the user interface functions stop worki
> >>>>>>>>>>>> ng.
> >>>>>>>>>>>> It
> >>>>>>>>>>> takes
> >>>>>>>>>>>> me quite a while to get my chart back to trading fast after
> >>>>>>>>>>>> using
> >>>>>>>>>>> more
> >>>>>>>>>>>> bars for a (not so) quick test.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Of course, once the user takes control of the number of
> >>>>>>>>>>>> bars
> >>>>>>>>>>> required,
> >>>>>>>>>>>> it is his responsibility to monitor the requirements
> >>> carefully.
> >>>>>>>>>>>>
> >>>>>>>>>>>> BR,
> >>>>>>>>>>>> Dennis
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jun 28, 2009, at 9:17 PM, bruce1r wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> > Dennis -
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Close, but not quite. If you were going to use
> >>>>>>>>>>>> > SetBarsRequired( )
> >>>>>>>>>>> to
> >>>>>>>>>>>> > control the lookback, it is CRITICAL that it be the LAST
> >>>>>>>>>>> statement in
> >>>>>>>>>>>> > the program. If it is not, subsequent statements ( such as
> >>>>>>>>>>>> > HHV() )
> >>>>>>>>>>>> > may
> >>>>>>>>>>>> > add to the requirement. If you want to see a detailed
> >>>>>>>>>>> explanation of
> >>>>>>>>>>>> > this, refer to Tomasz's QuickAFL article in the KB.
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Regarding the issues that you described in your previous
> >>>>>>>>>>> response to
> >>>>>>>>>>>> > me,
> >>>>>>>>>>>> > there are a couple of ways to deal with the issue that you
> >>> are
> >>>>>>>>>>>> > describing. When the teenagers go to bed and its quiet
> >>> later,
> >>>>>>>>>>>> > I'll
> >>>>>>>>>>>> > try
> >>>>>>>>>>>> > to outline one.
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > -- BruceR
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > --- In amibroker@xxxxxxxxx ps.com, Dennis Brown see3d@
> >>>>>>>>>>>> > wrote:
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> Yes Tony,
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> This is close to what I was referring to as the array
> >>>>>>>>>>>> >> solution,
> >>>>>>>>>>>> >> though
> >>>>>>>>>>>> >> I would probably write it like this to make it
> >>>>>>>>>>>> >> symmetrical:
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> minmax = LastValue( HHV( abs( m ), r ) );
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> It would be interesting if we could have a faster
> >>>>>>>>>>>> >> operation
> >>>>>>>>>>> such that
> >>>>>>>>>>>> >> if we used a SetBarsRequired( r, 0 ) in the preceding
> >>>>>>>>>>>> >> statement
> >>>>>>>>>>> to
> >>>>>>>>>>>> >> reduce the range so the the range equaled the number of
> >>> bars
> >>>>>>>>>>>> >> specified, that the returned value would be a single
> >>>>>>>>>>>> >> number
> >>>>>>>>>>>> >> of
> >>>>>>>>>>> the
> >>>>>>>>>>>> >> result. Hmmmmm. If that mode were available, it would
> >>>>>>>>>>>> >> look
> >>>>>>>>>>>> >> like
> >>>>>>>>>>>> > this:
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> m = MACD();
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> fb = Status("FirstVisibl eBar");
> >>>>>>>>>>>> >> lb = Status("LastVisible Bar");
> >>>>>>>>>>>> >> 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("LastVisible Bar");
> >>>>>>>>>>>> >>> 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@xxxxxxxxx ps.com, Dennis Brown see3d@
> >>>>>>>>>>>> >>>> wrote:
> >>>>>>>>>>>> >>>>>
> >>>>>>>>>>>> >>>>> Yes, I have it set to 100%. The absolute values of the
> >>>>>>>>>>> indicator
> >>>>>>>>>>>> >>>>> will
> >>>>>>>>>>>> >>>>> vary wildly, depending on the price and volatility of
> >>> the
> >>>>>>>>>>> stock.
> >>>>>>>>>>>> > I
> >>>>>>>>>>>> >>> & gt;> plot ES, so the values are quite large at times.
> >>>>>>>>>>>> >>>>>
> >>>>>>>>>>>> >>>>> BR,
> >>>>>>>>>>>> >>>>> Dennis
> >>>>>>>>>>>> >>>>>
> >>>>>>>>>>>> >>>>> On Jun 26, 2009, at 5:58 PM, monitorit wrote:
> >>>>>>>>>>>> >>>>>
> >>>>>>>>>>>> >>>>>> If that's all you needed, the color change would be
> >>> best.
> >>>>>>>>>>> But, I
> >>>>>>>>>>>> >>>>>> think the solution I suggested would work... you
> >>>>>>>>>>>> >>>>>> would
> >>>>>>>>>>>> >>>>>> still
> >>>>>>>>>>>> > plot/
> >>>>>>>>>>>> >>>>>> see value very high or low just within a section
> >>>>>>>>>>>> >>>>>> defined by
> >>>>>>>>>>>> >>> pane*1/
> >>>>>>>>>>>> >>>>>> minvalue [at least it has for me]. BTW, presently
> >>>>>>>>>>>> >>>>>> what
> >>> is
> >>>>>>>>>>>> >>>>>> the
> >>>>>>>>>>>> >>> upper
> >>>>>>>>>>>> >>>>>> and lower bounds of the MACD in relationship to the
> >>>>>>>>>>>> >>>>>> height
> >>>>>>>>>>>> >>>>>> of
> >>>>>>>>>>>> > the
> >>>>>>>>>>>> >>>>>> pane? Is it 100% of the pane height?
> >>>>>>>>>>>> >>>>>> Dan
> >>>>>>>>>>>> >>>>> ;>
> >>>>>>>>>>>> >>>>>> --- In amibroker@xxxxxxxxx ps.com, Dennis Brown
> >>>>>>>>>>>> >>>>>> <see3d@>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>> Dan,
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>> This is what I usually do for indicators when I know
> >>> the
> >>>>>>>>>>> range
> >>>>>>>>>>>> > of
> >>>>>>>>>>>> >>>>>>> values. However, MACD is an unbounded indicator,
> >>>>>>>>>>>> >>>>>>> so I
> >>>>>>>>>>>> >>>>>>> don't
> >>>>>>>>>>>> > know
> >>>>>>>>>>>> >>>>>>> how
> >>>>>>>>>>>> >>>>>>> large the values are. It is only the zero crossings
> >>> and
> >>>>>>>>>>>> > relative
> >>>>>>>>>>>> >>>>>>> peaks that are useful info here.
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>> I just thought there would be some simple shortcut
> >>>>>>>>>>>> >>>>>>> to
> >>>>>>>>>>> actually
> >>>>>>>>>>>> >>>>>>> scanning the visible bars for the min/max values to
> >>>>>>>>>>>> >>>>>>> use in
> >>>>>>>>>>> the
> >>>>>>>>>>>> >>> plot
> >>>>>>>>>>>> >>>>>>> statemen ts. I think I will just switch colors of
> >>>>>>>>>>>> >>>>>>> the
> >>>>>>>>>>>> >>>>>>> MACD
> >>>>>>>>>>> from
> >>>>>>>>>>>> >>> red
> >>>>>>>>>>>> >>>>>>> to
> >>>>>>>>>>>> >>>>>>> green if it is above or below zero instead of
> >>>>>>>>>>>> >>>>>>> resorting to
> >>>>>>>>>>> yet
> >>>>>>>>>>>> >>>>>>> another
> >>>>>>>>>>>> >>>>>>> loop.
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>> Thanks,
> >>>>>>>>>>>> >>>>>>> Dennis
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>> On Jun 26, 2009, at 4:40 PM, monitorit wrote:
> >>>>>>>>>>>> >>>>>>>
> >>>>>>>>>>>> >>>>>>>> Dennis,
> >>>>>>>>>>>> >>>>>>>> Hi. You might try this- Place a value in minvalue
> >>>>>>>>>>>> >>>>>>>> section
> >>>>>>>>>>> but
> >>>>>>>>>>>> >>>>>>>> none
> >>>>>>>>>>>> >>>>>>>> in maxvalue section [I think maybe a value like 2
> >>>>>>>>>>>> >>>>>>>> equates
> >>>>>>>>>>> to
> >>>>>>>>>>>> > 1/2
> >>>>>>>>>>>> >>>>>>>> pan e height] of your MACD and zero plot
> >>>>>>>>>>>> >>>>>>>> statements.
> >>>>>>>>>>>> >>>>>>>> Also,styleNoRescale in the zero plot statement.
> >>>>>>>>>>>> >>>>>>>> This
> >>>>>>>>>>>> >>>>>>>> worked
> >>>>>>>>>>>> > for
> >>>>>>>>>>>> >>>>>>>> me
> >>>>>>>>>>>> >>>>>>>> when I wanted to plot a histogram and a dot on the
> >>>>>>>>>>>> >>>>>>>> top of
> >>>>>>>>>>> the
> >>>>>>>>>>>> >>>>>>>> histogram. Not sure if it works with a line. If it
> >>>>>>>>>>>> >>>>>>>> doesn't,
> >>>>>>>>>>>> > you
> >>>>>>>>>>>> >>>>>>>> could try plotohlc with H=max(0,my#) and
> >>> L=min(0,my#) .
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> Dan
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> --- In amibroker@xxxxxxxxx ps.com, Dennis Brown
> >>> <see3d@>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> >>>>>>>>>
> >>>>>>>>>>>> >>>>>>>>> Hello,
> >>>>>>>>>>>> >>>>>>>>>
> >>>>>>>>>>>> >>>>>>>>> This must be simple, but my AFL brain is fried
> >>>>>>>>>>>> >>>>>>>>> today. I
> >>>>>>>>>>> have
> >>>>>>>>>>>> > an
> >>>>>>>>>>>> >>>>>>>>> MACD
> >>>>>>>>>>>> >>>>>>>>> plot on top of my main price chart, and I want to
> >>>>>>>>>>>> >>>>>>>>> plot a
> >>>>>>>>>>> zero
> >>>>>>>>>>>> >>>>>>>>> line
> >>>>>>>>>>>> >>>>>>>>> over it. It is plotted as StyleOwnScale of
> >>>>>>>>>>>> >>>>>>>>> course. I
> >>>>>>>>>>>> >>>>>>>>> can't
> >>>>>>>>>>>> > use
> >>>>>>>>>>>> >>>>>>>>> StyleLeftAxis because I am using it for something
> >>>>>>>>>>>> >>>>>>>>> else. I
> >>>>>>>>>>>> >>>>>>>>> guess I
> >>>>>>>>>>>> >>>>>>>>> could do something to figure out where the visible
> >>>>>>>>>>>> >>>>>>>>> high
> >>>>>>>>>>> and
> >>>>>>>>>>>> > low
> >>>>>>>>>>>> >>>>>>>>> values
> >>>>>>>>>>>> >>>>>>>>> of the MACD are, but it seems like it should be
> >>> easier
> >>>>>>>>>>> than
> >>>>>>>>>>>> >>> that.
> >>>>>>>>>>>> >>>>>>>>>
> >>>>>>>>>>>> >>>>>>>>> TIA,
> >>>>>>>>>>>> >>>>>>>>> Dennis
> >>>>>>>>>>>> >>>>>>>>>
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> ------------ --------- --------- ------
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>>>>> >>>>>>>> This group is for the discussion between users
> >>>>>>>>>>>> >>>>>>>> only.
> >>>>>>>>>>>> >>>>>>>> This is *NOT* technical support channel.
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>>>>>>>> >>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>>>>>>>> >>>>>>>> http://www.amibroke r.com/feedback/
> >>>>>>>>>>>> >>>>>>>> (submissions sent via other channels won't be
> >>>>>>>>>>>> >>>>>>>> considered)
> >>>>>>>>>>>> >>>>>>>>
> >>>>>>>>>>>> >>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always
> >>>>>>>>>>>> >>>>>>>> check
> >>>>>>>>>>>> >>> DEVLOG:
> >>>>>>>>>>>> >>>>>>>> http://www.amibroke r.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.amibroke r.com/feedback/
> >>>>>>>>>>>> >>>>>> (submissions sent via other channels won't be
> >>> considered)
> >>>>>>>>>>>> >>>>>>
> >>>>>>>>>>>> >>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always
> >>> check
> >>>>>>>>>>>> > DEVLOG:
> >>>>>>>>>>>> >>>>>> http://www.amibroke r.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.amibroke r.com/feedback/
> >>>>>>>>>>>> >>>> (submissions sent via other channels won't be
> >>>>>>>>>>>> >>>> considered)
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> For NEW RELEASE ANNOUNCEMENTS and other news always
> >>>>>>>>>>>> >>>> check
> >>>>>>>>>>> DEVLOG:
> >>>>>>>>>>>> >>>> http://www.amibroke r.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.amibroke r.com/feedback/
> >>>>>>>>>>>> > (submissions sent via other channels won't be considered)
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > For NEW RELEASE ANNOUNCEMENTS and other news always check
> >>>>>>>>>>>> > DEVLOG:
> >>>>>>>>>>>> > http://www.amibroke r.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.amibroke r.com/feedback/
> >>>>>>>> (submissions sent via other channels won't be considered)
> >>>>>>>>
> >>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check
> >>>>>>>> DEVLOG:
> >>>>>>>> http://www.amibroke r.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.amibroke r.com/feedback/
> >>>>> (submissions sent via other channels won't be considered)
> >>>>>
> >>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> >>>>> http://www.amibroke r.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.amibroke r.com/feedback/
> > (submissions sent via other channels won't be considered)
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroke r.com/devlog/
> >
> > Yahoo! Groups Links
> >
> >
> >
>