|
PureBytes Links
Trading Reference Links
|
That should be
(load100/execute100)process2;
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> 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@> 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/
|