|
PureBytes Links
Trading Reference Links
|
In that case ...
- if
load/execute;
load/execute;
load/execute;
is the efficient model?
- why is
(load1000/execute1000)process1;
(load1000/execute1000)process2;
(load1000/execute1000)process3;
more efficient than
(load1000/execute1000)process1;
(load1000/execute100)process2;
(load1000/execute1000)process3;
I just got out of bed ... haven't even had breakfast yet!
--- In amibroker@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, "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@xxxxxxxxxxxxxxx, "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@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
<*> 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/
|