|
PureBytes Links
Trading Reference Links
|
Tomasz has given examples in the past. there is a way to have pretty much just lines. but I havent used it for awhile, so I've forgotten.
Try looking after example of stylecloud, colorhue, and colorrgb.
--- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>
> Paul,
>
> Thanks. This would identify both the zero and MACD levels. It would
> almost be what I wanted except it obscures too much of my chart when
> plotted that way. I have a lot of data on my chart at the same time.
> Sorry about not splitting all the SBR stuff into its own thread. That
> is what the thread has morphed into.
>
> BR,
> Dennis
>
> On Jul 1, 2009, at 2:31 AM, Paul Ho wrote:
>
> > by the way,
> > what you orginally asked for isn't it as simply as
> >
> > ml = MACD(r1, r2);
> > PlotOHLC(ml, ml, 0, 0, "dennis", WhateverColor, styleCloud|
> > styleOwnScale);
> >
> > How come it has now become war and peace? I have obviously missed
> > out a whole lot in between.....:)
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >>
> >> Dennis
> >> Wouldn't dream of suggesting to you writing the whole lot in dll.
> >> You dont have a problem with the rest of your code, right? at least
> >> at far as I can follow.
> >> My comment is only related to the what you're trying to solve with
> >> a variable/flexible SBR. In other words, a dll function for
> >> marshalling of 200K bars, that function would check if work has
> >> been done already, if so, just return without further to do, if
> >> not, manage the 200k bars with what you need to do, allocate memory
> >> as I have outlined before. To do that should take only a fraction
> >> of a second if you can limit to a minimum of 200K bar arrays at
> >> 800Kb each. As to the rest of the code, you can easily leave it the
> >> way it is.
> >>
> >> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >>>
> >>> Hi Paul,
> >>>
> >>> Thanks for your comments. A 100 fold speed improvement in
> >>> processing
> >>> 100,000 bars for a backtest environment would indeed be nice.
> >>> However, I doubt it could be made more than 10 times faster, which
> >>> would still be nice. I hear what you are saying: just write my
> >>> algorithms in C++ and forget about AFL for anything other than
> >>> housekeeping. This may be a valid solution for a production system,
> >>> or doing certain time consuming algorithms, but I did not buy
> >>> Amibroker so that I could learn to code my systems in C++, I
> >>> bought it
> >>> so I could code them in a higher level array language. One
> >>> development platform only please. (Besides, if I was going to write
> >>> everything myself, I would throw away XP and do it all in OS X. I
> >>> don't like MS software at all -- I only barely tolerate XP so I can
> >>> run AB). My system is about 8500 lines of AFL source code. Less
> >>> than
> >>> half of that is my actual algorithms working on arrays. The rest is
> >>> used to make AB into a systems development platform the way I like
> >>> it. I only have one chart and one ticker that I use. I only run an
> >>> indicator for trading. Each system has about 1000 parameters
> >>> saved on
> >>> disk. Having everything in readily available source for editing and
> >>> running as an interpreter (AFL) makes it much easier for me to debug
> >>> and maintain the system. It is still in development, (even though I
> >>> am trading with it now), and it will probably be in development for
> >>> years to come. Just because it is possible to write everything in
> >>> C++
> >>> does not mean that it is an excuse for not having good support for
> >>> better low level functionality in AFL for able programmers.
> >>> However,
> >>> I do have some very specialized algorithms for processing geometry
> >>> that would make sense to put into a DLL for speed purposes -- once I
> >>> am happy with the prototype AFL code. I also have some different
> >>> kinds of filters that could be turned into DLLs for speed. However,
> >>> these would only improve speed by 10-20% at most. I don't calculate
> >>> things more often than needed, but as you say I end up with a lot of
> >>> arrays in the process of combining multiple systems into a single
> >>> one. My needs are straight forward, but the thread has become a
> >>> sounding board for different people that see things in a different
> >>> light. It has made for a confusing jumble to try to follow, and
> >>> should have been spawned into several more threads. My brain was
> >>> fried when I started it, but I am fully recovered at this point. Oh
> >>> well, thats life on the big board. LOL
> >>>
> >>> BR,
> >>> Dennis
> >>>
> >>>
> >>> On Jun 30, 2009, at 10:44 PM, Paul Ho wrote:
> >>>
> >>>> Dennis
> >>>> The discussion seems to have shifted towards having AB allowing a
> >>>> more flexible regime in SBR from some brain fried topics in order
> >>>> to
> >>>> solve quite a specific situation that you have.
> >>>> I think your problem can be solved right now if you looked at it
> >>>> from a memory managment and performance perspective.
> >>>> Lets take 200000 bars as an example, 200K bars of a single array is
> >>>> 800K bytes, not very much. but a 100 of them will take 80M. it
> >>>> starts to mount up. In afl, unless you are very careful, you will
> >>>> easily doing a 100 array processings with a few lines here and
> >>>> there. secondly, you only need to do it once, I dont know if it is
> >>>> once a day, once in awhile..... but you dont do it very often.
> >>>> AFL was designed so that users dont have to worry anything about
> >>>> memory mangement, if an user wants the capability to manage the
> >>>> resource being used for a specific situation. then dll is the
> >>>> answer. In dll, you will have complete control how much and in what
> >>>> way memory is allocated. I have done that sort of things many
> >>>> times,
> >>>> you take over the allocation and dellocation memory yourself inside
> >>>> your dll, by passing tomasz's memory allocation routine. As you are
> >>>> writing code and allocating memory specific for your problem. You
> >>>> can be a lot more economical than any general algorithm would. you
> >>>> can build in controls that it is only executed when it is needed.
> >>>> The results is a much faster and elagent solution, In all my
> >>>> exprience, and I dont know how complex your stuff is, but from your
> >>>> description, it doenst sound very complex, you should be able to
> >>>> get
> >>>> the time down to a fraction of second for 200K bars.
> >>>>
> >>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >>>>>
> >>>>> Brian,
> >>>>>
> >>>>> I believe that Tomasz is quite good at how he allocates and
> >>>>> deallocates memory internally for arrays. Also if you are only
> >>>>> talking about a few thousand bars, more time could be lost in
> >>>>> trying
> >>>>> to shuffle things around than just using all the bars. My minimum
> >>>>> number of bars for a calculation is 7,000. That is just to get
> >>>>> accurate real time trading signals. For backtesting, I use
> >>>>> 200,000
> >>>>> bars. When you are talking high bar counts, then being able to
> >>>>> have
> >>>>> control over the calculation size of the arrays can amount to some
> >>>>> serious time savings.
> >>>>>
> >>>>> However, you are right in that if a large number of bars is only
> >>>>> needed for an occasional calculation to generate some reference
> >>>>> data,
> >>>>> then it can be costly in time and space to make everything have to
> >>>>> use
> >>>>> all the bars. That is something that would take a programmer to
> >>>>> recognize and be able to optimize.
> >>>>>
> >>>>> I look for cases where I can take advantage of these cases. So
> >>>>> far,
> >>>>> the only way to do this was to save the data to something like
> >>>>> an ATC
> >>>>> ticker and use foreign to access the data, or to run two
> >>>>> different
> >>>>> charts at different refresh rates and have them communicate their
> >>>>> data
> >>>>> via static variables.
> >>>>>
> >>>>> Trying to have AB figure out all this on the fly is complicated
> >>>>> and
> >>>>> beyond my understanding of how it could be done.
> >>>>>
> >>>>> BR,
> >>>>> Dennis
> >>>>>
> >>>>>
> >>>>> On Jun 30, 2009, at 9:38 AM, brian_z111 wrote:
> >>>>>
> >>>>>>> if RAM needs reorganizing, save the last 100 bars from the
> >>>>>>> variables >etc calculated on 1000 bars e.g. static arrays etc,
> >>>>>>> dump
> >>>>>>> the rest >and then reload the new global SBR # bars i.e. 100.
> >>>>>>
> >>>>>>
> >>>>>> What I meant to ask there was if it is possible to dump some data
> >>>>>> out of RAM and keep a smaller amount that you will need
> >>>>>> thereafter ... maybe move it around in RAM to to where it is
> >>>>>> needed
> >>>>>> without the need to start again by dumping the lot and reading
> >>>>>> 100
> >>>>>> bars in from the disc again.
> >>>>>>
> >>>>>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Well, if my assumptions so far are more or less correct then
> >>>>>>> that
> >>>>>>> leads me towards another possibility ........
> >>>>>>>
> >>>>>>>
> >>>>>>> ...... depending on how RAM memory works (not sure about that)
> >>>>>>>
> >>>>>>> - assuming a database of 5000 bars
> >>>>>>>
> >>>>>>> - if we need a large number of bars, say 1000, to calculate a
> >>>>>>> long
> >>>>>>> term indicator, or indicators ... if this was the largest bar
> >>>>>>> requirement it could become the coded global SBR setting (I
> >>>>>>> assume
> >>>>>>> that this setting might make the need to load all bars for the
> >>>>>>> first pass obsolete ... possibly polling all bars on the first
> >>>>>>> pass
> >>>>>>> has a function (check if bars are not null value, maybe?) ...
> >>>>>>> assuming this function can be passed to the global SBR bars then
> >>>>>>> putting the global SBR at the head of the code could drive AB to
> >>>>>>> load only 1000 bars.
> >>>>>>>
> >>>>>>> - assuming that the 1000 bars are only need for a one off
> >>>>>>> calc ...
> >>>>>>> if we leave them all there will they restrict RAM availability
> >>>>>>> for
> >>>>>>> other uses (as I said I am not sure if contiguous memory on the
> >>>>>>> disc translates into contiguous memory in RAM) ... if there is
> >>>>>>> any
> >>>>>>> RAM advantage to be gained then a second global SBR command,
> >>>>>>> set
> >>>>>>> to, say 100 bars, that comes after the block of code that needed
> >>>>>>> 1000 bars, could trigger off a dump of the 900 bars no longer
> >>>>>>> need
> >>>>>>> OR of RAM needs reorganizing, save the last 100 bars from the
> >>>>>>> variables etc calculated on 1000 bars e.g. static arrays etc,
> >>>>>>> dump
> >>>>>>> the rest and then reload the new global SBR # bars i.e. 100.
> >>>>>>>
> >>>>>>> Blocks of code that only need < 100 bars could then be
> >>>>>>> controlled
> >>>>>>> via local SBR settings (one for each block).
> >>>>>>>
> >>>>>>>
> >>>>>>> Beyond that idea #3 keeps coming back to me.......
> >>>>>>>
> >>>>>>> i.e. that AB could, should, would poll the CPU for
> >>>>>>> availability and
> >>>>>>> prioritize processing tasks.
> >>>>>>>
> >>>>>>> Some kind of flow control for the order of execution could be a
> >>>>>>> tiny step in that direction i.e. reprocessing of a block of
> >>>>>>> code,
> >>>>>>> with a large number of bars, might be set to low priority (if
> >>>>>>> you
> >>>>>>> only need the answer every now and then) and AB would feed it to
> >>>>>>> the processor a bit at a time (when the processor is not busy on
> >>>>>>> your hot short term code).
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >>>>>>>>
> >>>>>>>> Brian,
> >>>>>>>>
> >>>>>>>> Yes there are two pieces. The number of bars loaded, and the
> >>>>>>>> number
> >>>>>>>> of bars used in an array calculation. Both are important for
> >>>>>>>> speed,
> >>>>>>>> but the number used for array calculations can make the most
> >>>>>>>> difference if it can be reduced. It would take a comprehensive
> >>>>>>>> discussion of all the different possibilities and what could be
> >>>>>>>> gained
> >>>>>>>> be each one to clarify all the issues. Bruce hinted that
> >>>>>>>> that has
> >>>>>>>> already taken place in the past with TJ. My simplest case is
> >>>>>>>> just
> >>>>>>>> to
> >>>>>>>> allow the SBR in future passes to reduce the number of bars
> >>>>>>>> like
> >>>>>>>> possible on the first pass.
> >>>>>>>>
> >>>>>>>> BR,
> >>>>>>>> Dennis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Jun 30, 2009, at 5:44 AM, brian_z111 wrote:
> >>>>>>>>
> >>>>>>>>> Clarification:
> >>>>>>>>>
> >>>>>>>>> The longest SBR, of the complete formula, could be the
> >>>>>>>>> primary
> >>>>>>>>> (global)SBR, and control the # bars loaded into memory,
> >>>>>>>>> while the secondary SBR's set how many of the bars already
> >>>>>>>>> loaded
> >>>>>>>>> into memory to actually use, for any particular block of
> >>>>>>>>> code (as
> >>>>>>>>> defined by the local
> >>>>>>>>> SBR's???????????????????????????????????????
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I still have a few questions about this.
> >>>>>>>>>>
> >>>>>>>>>> FTR:
> >>>>>>>>>>
> >>>>>>>>>> I am OK with the idea so far ... I am wondering about the
> >>>>>>>>>> practicality of the implementation though... I guess you guys
> >>>>>>>>>> (Fred,Bruce,Dennis), being programmers, are confident you are
> >>>>>>>>>> going
> >>>>>>>>>> to gain time, either when running long BT's or Opts OR only
> >>>>>>>>>> in
> >>>>>>>>>> RT
> >>>>>>>>>> charts?
> >>>>>>>>>>
> >>>>>>>>>> Does anyone have any idea where these gains would come
> >>>>>>>>>> from, or
> >>>>>>>>>> how
> >>>>>>>>>> they could be achieved, in processing terms .... what sort of
> >>>>>>>>>> time
> >>>>>>>>>> gains can we expect if Tomasz does decide to action the idea?
> >>>>>>>>>>
> >>>>>>>>>> When Dennis said that calling SBR with a lower # bars
> >>>>>>>>>> RESTARTS
> >>>>>>>>>> the
> >>>>>>>>>> charts I am guessing that he means bars are reloaded into
> >>>>>>>>>> memory,
> >>>>>>>>>> thus rebuilding the charts.... is this the default behaviour?
> >>>>>>>>>>
> >>>>>>>>>> .. if so this would be the default for any change of setting
> >>>>>>>>>> (either up or down) so any change of setting has this
> >>>>>>>>>> 'penalty'
> >>>>>>>>>> attached?
> >>>>>>>>>>
> >>>>>>>>>> Are you guys suggesting that, where two or more calls are
> >>>>>>>>>> made
> >>>>>>>>>> to
> >>>>>>>>>> SBR() that AB could still estimate max bars required for the
> >>>>>>>>>> longest SBR after the first pass, keep them in memory, but
> >>>>>>>>>> only
> >>>>>>>>>> access the number required for each subsequent block of
> >>>>>>>>>> shorter
> >>>>>>>>>> length arrays .... i.e. where there are more than one SBR
> >>>>>>>>>> in a
> >>>>>>>>>> formula, the longest SBR will be the primary SBR, and control
> >>>>>>>>>> the #
> >>>>>>>>>> bars loaded, while the secondary SBR's set how many of the
> >>>>>>>>>> loaded
> >>>>>>>>>> bars to actually use?
> >>>>>>>>>>
> >>>>>>>>>> I don't know if instructing AB to change to using, say, 10
> >>>>>>>>>> bars,
> >>>>>>>>>> from a loaded memory of, say, 100, has much of a time penalty
> >>>>>>>>>> attached to it ... I guess not?
> >>>>>>>>>>
> >>>>>>>>>> I don't understand how processors work so I am not certain
> >>>>>>>>>> that
> >>>>>>>>>> this would lead to a time gains ... I guess if there are
> >>>>>>>>>> gains
> >>>>>>>>>> to
> >>>>>>>>>> be had, by this method, it would depend on how long it
> >>>>>>>>>> takes to
> >>>>>>>>>> change the no bars actually processed and ... how many
> >>>>>>>>>> lines of
> >>>>>>>>>> code are included in the short array block.
> >>>>>>>>>>
> >>>>>>>>>> I assume that processing 10 bars, already in memory, is
> >>>>>>>>>> actually
> >>>>>>>>>> faster than processing the whole 100, already in memory ....
> >>>>>>>>>> that
> >>>>>>>>>> is a big assumption on my part (could be wrong!).
> >>>>>>>>>>
> >>>>>>>>>> Is that what you guys are suggesting or is it something else?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Bruce,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for your suggestions. They are appreciated. I will
> >>>>>>>>>>> contact
> >>>>>>>>>>> you off-line for further discussion about these.
> >>>>>>>>>>>
> >>>>>>>>>>> I am glad to see that I am not the only one who would like
> >>>>>>>>>>> to
> >>>>>>>>>>> have
> >>>>>>>>>>> more control over the number of bars used in AFL. I
> >>>>>>>>>>> posted one
> >>>>>>>>>>> bug
> >>>>>>>>>>> related to these long ago, and commented on the one way
> >>>>>>>>>>> nature of
> >>>>>>>>>>> SBR,
> >>>>>>>>>>> but never posted my own suggestion for having the ability to
> >>>>>>>>>>> reduce
> >>>>>>>>>>> the number of bars via SBR, because I previously could not
> >>>>>>>>>>> get
> >>>>>>>>>>> any
> >>>>>>>>>>> responses from this forum or support about how I should go
> >>>>>>>>>>> about
> >>>>>>>>>>> trying to do this. I did not want to suggest something
> >>>>>>>>>>> without
> >>>>>>>>>>> knowing it was desired by more than myself, or
> >>>>>>>>>>> understanding if
> >>>>>>>>>>> there
> >>>>>>>>>>> was another way to do it. I have now posted a suggestion
> >>>>>>>>>>> #1790,
> >>>>>>>>>>> so we
> >>>>>>>>>>> have a place holder for the desired functionality. http://www.amibroker.com/feedback/view_bug.php?bug_id=1790
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>> Dennis
> >>>>>>>>>>>
> >>>>>>>>>>> On Jun 29, 2009, at 9:19 AM, bruce1r wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Dennis -
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was just making sure about you understanding of the
> >>>>>>>>>>>> SetBarsRequired() placement. I agree with most of your
> >>>>>>>>>>>> summary,
> >>>>>>>>>>>> but
> >>>>>>>>>>>> let's put the minor points aside and turn to your issue.
> >>>>>>>>>>>> FWIW, I'd
> >>>>>>>>>>>> like to have full control over bar requirements also.
> >>>>>>>>>>>> Actually -
> >>>>>>>>>>>> even more than you want, but that's another story. Its
> >>>>>>>>>>>> something
> >>>>>>>>>>>> that I and Fred and I have both discussed with Tomasz some
> >>>>>>>>>>>> time
> >>>>>>>>>>>> ago. I might even muse on TJ's reasoning in his current
> >>>>>>>>>>>> design,
> >>>>>>>>>>>> but
> >>>>>>>>>>>> he really should comment. But, we have to deal with the
> >>>>>>>>>>>> hand
> >>>>>>>>>>>> that
> >>>>>>>>>>>> we're dealt.
> >>>>>>>>>>>>
> >>>>>>>>>>>> My impression is that you have an "all in one" indicator
> >>>>>>>>>>>> that
> >>>>>>>>>>>> you
> >>>>>>>>>>>> try to use as a control and analysis center. I'll confess
> >>>>>>>>>>>> that
> >>>>>>>>>>>> I've written one of these also, but moved away from that
> >>>>>>>>>>>> type of
> >>>>>>>>>>>> design for various reasons. I think that we are at a point
> >>>>>>>>>>>> that if
> >>>>>>>>>>>> you want to explore some workarounds, we'll have to examine
> >>>>>>>>>>>> your
> >>>>>>>>>>>> requirements in detail, and this is probably best moved o
> >>>>>>>>>>>> ffline to
> >>>>>>>>>>>> e-mail.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Before I do that, I'll offer some comments that I hope
> >>>>>>>>>>>> might
> >>>>>>>>>>>> be of
> >>>>>>>>>>>> general interest about this general problem. Let's recap
> >>>>>>>>>>>> your
> >>>>>>>>>>>> statement about the design issue -
> >>>>>>>>>>>>
> >>>>>>>>>>>> You said - "In my case, I sometimes want to take a one shot
> >>>>>>>>>>>> pass at
> >>>>>>>>>>>> allthe bars to gather some statistics and save them, then
> >>>>>>>>>>>> immediately dropback to some minimum number of bars to
> >>>>>>>>>>>> speed
> >>>>>>>>>>>> up the
> >>>>>>>>>>>> user interface for changing parameters in the parameter
> >>>>>>>>>>>> window
> >>>>>>>>>>>> or
> >>>>>>>>>>>> even working with on-chart buttons, and go back to real
> >>>>>>>>>>>> time
> >>>>>>>>>>>> trading."
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, given that as the problem statement, some alternatives
> >>>>>>>>>>>> are -
> >>>>>>>>>>>> Note that having say SetBarsRequired(100,0), for example,
> >>>>>>>>>>>> DOES NOT
> >>>>>>>>>>>> preclude passing all of the data. I suspect that what you
> >>>>>>>>>>>> want
> >>>>>>>>>>>> is
> >>>>>>>>>>>> to
> >>>>>>>>>>>> expand the back bars then call Equity() and gather
> >>>>>>>>>>>> stats. A
> >>>>>>>>>>>> viable
> >>>>>>>>>>>> alternative in some cases is just to programatically zoom
> >>>>>>>>>>>> to
> >>>>>>>>>>>> the
> >>>>>>>>>>>> full range, run and store the stats,and programatically
> >>>>>>>>>>>> zoom
> >>>>>>>>>>>> back
> >>>>>>>>>>>> to
> >>>>>>>>>>>> the original range. This preserves the 100 bars back
> >>>>>>>>>>>> setting.
> >>>>>>>>>>>> Another slightly more flexible alternative is to run the
> >>>>>>>>>>>> backtestin
> >>>>>>>>>>>> the AA. To do this, you shell out to a JScript
> >>>>>>>>>>>> "controller"
> >>>>>>>>>>>> program
> >>>>>>>>>>>> which invokes the appropriate AA backtest and stores the
> >>>>>>>>>>>> results.
> >>>>>>>>>>>> In your case, though, this might require the passing of
> >>>>>>>>>>>> many
> >>>>>>>>>>>> parameters in static variables, though. However, I use
> >>>>>>>>>>>> this
> >>>>>>>>>>>> technique for running a portfolio backtest over a dynamic
> >>>>>>>>>>>> watchlist
> >>>>>>>>>>>> on demand from an indicator. BTW, it seems to "free up"
> >>>>>>>>>>>> the
> >>>>>>>>>>>> indicator display, but I have only run this on EOD data and
> >>>>>>>>>>>> can't
> >>>>>>>>>>>> comment on how much parallelism can be achieved on RT data.
> >>>>>>>>>>>> And, I
> >>>>>>>>>>>> assume that TJ has the appropriate lock-outs, but after
> >>>>>>>>>>>> about a
> >>>>>>>>>>>> year
> >>>>>>>>>>>> and a half of use, no problems.
> >>>>>>>>>>>> The backtest "indicator" can be run in another document.
> >>>>>>>>>>>> This
> >>>>>>>>>>>> document can have a different, full data range. This has
> >>>>>>>>>>>> the
> >>>>>>>>>>>> advantage of only calculating when when visible, but I'd
> >>>>>>>>>>>> still
> >>>>>>>>>>>> put a
> >>>>>>>>>>>> trigger on it. But, again, some parameter communication
> >>>>>>>>>>>> would
> >>>>>>>>>>>> be
> >>>>>>>>>>>> needed.
> >>>>>>>>>>>> Each individual would have to decide on the trade-off's.
> >>>>>>>>>>>> #1 is
> >>>>>>>>>>>> the
> >>>>>>>>>>>> easiest. #2 might allow for some interesting things if and
> >>>>>>>>>>>> when TJ
> >>>>>>>>>>>> implements multi-processor support. There are even a few
> >>>>>>>>>>>> other
> >>>>>>>>>>>> alternatives. But this is probably enough food for
> >>>>>>>>>>>> thought.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -- BruceR
> >>>>>>>>>>>>
> >>>>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Bruce,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, I understand the SBR requirements. My AFLs have it as
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> last
> >>>>>>>>>>>>> statement. The thing I was showing below was some wishful
> >>>>>>>>>>>>> thinking
> >>>>>>>>>>>> if
> >>>>>>>>>>>>> the way SBR worked were modified to allow for reducing the
> >>>>>>>>>>>>> number of
> >>>>>>>>>>>>> bars at each call. In fact it would be good to iterate
> >>>>>>>>>>>>> how it
> >>>>>>>>>>>>> works
> >>>>>>>>>>>>> here so nobody gets confused by my musings:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When the indicator chart is first run, it takes a pass
> >>>>>>>>>>>>> just
> >>>>>>>>>>>>> to
> >>>>>>>>>>>> figure
> >>>>>>>>>>>>> out how man y bars are required (it also compiles other
> >>>>>>>>>>>> information to
> >>>>>>>>>>>>> speed executions). Each function, or loop may have a
> >>>>>>>>>>>>> different
> >>>>>>>>>>>>> requirement for historical bars previous to the
> >>>>>>>>>>>>> FirstVisibleBar.
> >>>>>>>>>>>> This
> >>>>>>>>>>>>> first AFL pass might give erroneous results since it
> >>>>>>>>>>>>> does not
> >>>>>>>>>>>>> know
> >>>>>>>>>>>>> until the end of the pass what all the requirements are,
> >>>>>>>>>>>>> but I
> >>>>>>>>>>>>> think
> >>>>>>>>>>>>> it uses all bars, so that should not cause a problem. It
> >>>>>>>>>>>>> is a
> >>>>>>>>>>>>> peak
> >>>>>>>>>>>>> detecting function, so that it only increased the number
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>> bars
> >>>>>>>>>>>>> required, and never decreases them. If I have operations
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>> write
> >>>>>>>>>>>>> information to files or static variables, I disable the
> >>>>>>>>>>>>> writes
> >>>>>>>>>>>> during
> >>>>>>>>>>>>> this pass since the ChartID is not valid yet.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Subsequent AFL passes now know how many bars to load
> >>>>>>>>>>>>> from the
> >>>>>>>>>>>> database
> >>>>>>>>>>>>> to make sure that the visible bars show accurate results.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If some new conditional AFL code executes during one of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>> subsequent
> >>>>>>>>>>>> &g t; AFL passes, for instance an AddToComposite() function
> >>>>>>>>>>>> that
> >>>>>>>>>>>> requires
> >>>>>>>>>>>>> all bars, or an SetBarsRequired() function with a larger
> >>>>>>>>>>>>> number of
> >>>>>>>>>>>>> bars, the next pass of AFL will load more bars and this
> >>>>>>>>>>>>> will be
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> new minimum bars requirement. However, I have noticed in
> >>>>>>>>>>>>> my
> >>>>>>>>>>>>> charts,
> >>>>>>>>>>>>> that the first pass after a new requirement may not use
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> higher
> >>>>>>>>>>>>> number of bars for an extra pass, so I am not sure about
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> exact
> >>>>>>>>>>>>> sequence. Perhaps, a new requirement caused another "bar
> >>>>>>>>>>>>> requirements" gathering pass first. This can lead to
> >>>>>>>>>>>>> errors
> >>>>>>>>>>>>> if you
> >>>>>>>>>>>>> are saving results on a one shot basis in a static
> >>>>>>>>>>>>> variable
> >>>>>>>>>>>>> or
> >>>>>>>>>>>>> file.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If an SetBarsRequired() statement is found at the very
> >>>>>>>>>>>>> end of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>> AFL,
> >>>>>>>>>>>>> then it will override the previous requirements.
> >>>>>>>>>>>>> However, it
> >>>>>>>>>>>>> still
> >>>>>>>>>>>>> will not allow you to reduce the requirements after the
> >>>>>>>>>>>>> first
> >>>>>>>>>>>>> pass.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am not aware of any detailed descriptions or flow
> >>>>>>>>>>>>> charts of
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>> execution process for AFL, so all of this is just from
> >>>>>>>>>>>>> observations
> >>>>>>>>>>>>> while debugging code, and might be incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I was musing about giving the user AFL control over the
> >>>>>>>>>>>>> reducing
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> number of bars used on subsequent passes.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In my case, I sometimes want to take a one shot pass at
> >>>>>>>>>>>>> all
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> bars
> >>>>>>>>>>>>> to gather some statistics and save them, then immediately
> >>>>>>>>>>>>> drop
> >>>>>>>>>>>> back to
> >>>>>>>>>>>>> some minimum number of bars to speed up the user interface
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>> changing parameters in the parameter window or even
> >>>>>>>>>>>>> working
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>> on-
> >>>>>>>>>>>>> chart buttons, and go back to real time trading. It is a
> >>>>>>>>>>>>> real
> >>>>>>>>>>>>> drag
> >>>>>>>>>>>>> when I have to wait 5 seconds between every parameter
> >>>>>>>>>>>>> change --
> >>>>>>>>>>>> which
> >>>>>>>>>>>>> is the fastest I have been able to drop back to from the
> >>>>>>>>>>>>> 20
> >>>>>>>>>>>>> second
> >>>>>>>>>>>>> full pass with SBR working in its current operating mode.
> >>>>>>>>>>>>> At 5
> >>>>>>>>>>>>> seconds, a lot of the user interface functions stop
> >>>>>>>>>>>>> worki ng.
> >>>>>>>>>>>>> It
> >>>>>>>>>>>> takes
> >>>>>>>>>>>>> me quite a while to get my chart back to trading fast
> >>>>>>>>>>>>> after
> >>>>>>>>>>>>> using
> >>>>>>>>>>>> more
> >>>>>>>>>>>>> bars for a (not so) quick test.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Of course, once the user takes control of the number of
> >>>>>>>>>>>>> bars
> >>>>>>>>>>>> required,
> >>>>>>>>>>>>> it is his responsibility to monitor the requirements
> >>>>>>>>>>>>> carefully.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> BR,
> >>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Jun 28, 2009, at 9:17 PM, bruce1r wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Dennis -
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Close, but not quite. If you were going to use
> >>>>>>>>>>>>>> SetBarsRequired()
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> control the lookback, it is CRITICAL that it be the LAST
> >>>>>>>>>>>> statement in
> >>>>>>>>>>>>>> the program. If it is not, subsequent statements ( such
> >>>>>>>>>>>>>> as
> >>>>>>>>>>>>>> HHV() )
> >>>>>>>>>>>>>> may
> >>>>>>>>>>>>>> add to the requirement. If you want to see a detailed
> >>>>>>>>>>>> explanation of
> >>>>>>>>>>>>>> this, refer to Tomasz's QuickAFL article in the KB.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regarding the issues that you described in your previous
> >>>>>>>>>>>> response to
> >>>>>>>>>>>>>> me,
> >>>>>>>>>>>>>> there are a couple of ways to deal with the issue that
> >>>>>>>>>>>>>> you
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>> describing. When the teenagers go to bed and its quiet
> >>>>>>>>>>>>>> later,
> >>>>>>>>>>>>>> I'll
> >>>>>>>>>>>>>> try
> >>>>>>>>>>>>>> to outline one.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -- BruceR
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown see3d@
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes Tony,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is close to what I was referring to as the array
> >>>>>>>>>>>>>>> solution,
> >>>>>>>>>>>>>>> though
> >>>>>>>>>>>>>>> I would probably write it like this to make it
> >>>>>>>>>>>>>>> symmetrical:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> minmax = LastValue( HHV( abs( m ), r ) );
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It would be interesting if we could have a faster
> >>>>>>>>>>>>>>> operation
> >>>>>>>>>>>> such that
> >>>>>>>>>>>>>>> if we used a SetBarsRequired( r, 0 ) in the preceding
> >>>>>>>>>>>>>>> statement
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>> reduce the range so the the range equaled the number of
> >>>>>>>>>>>>>>> bars
> >>>>>>>>>>>>>>> specified, that the returned value would be a single
> >>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> result. Hmmmmm. If that mode were available, it would
> >>>>>>>>>>>>>>> look
> >>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>> this:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> m = MACD();
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> fb = Status("FirstVisibleBar");
> >>>>>>>>>>>>>>> lb = Status("LastVisibleBar");
> >>>>>>>>>>>>>>> r = lb - fb;
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> SetBarsRequired( r, 0 )
> >>>>>>>>>>>>>>> maximum = HHV( abs( m ), r );
> >>>>>>>>>>>>>>> Plot( m, "MACD", colorRed, styleOwnScale, -maximum,
> >>>>>>>>>>>>>>> maximum );
> >>>>>>>>>>>>>>> Plot(0, "", colorBlack, styleOwnScale, -maximum,
> >>>>>>>>>>>>>>> maximum);
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just a little brainstorming.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> BR,
> >>>>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Jun 28, 2009, at 8:31 AM, Tony Grimes wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Try this solution, array style:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> m = MACD();
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> fb = Status("FirstVisibl eBar");
> >>>>>>>>>>>>>>>> lb = Status("LastVisibleBar");
> >>>>>>>>>>>>>>>> r = lb - fb;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> minimum = LastValue( LLV( m, r ) );
> >>>>>>>>>>>>>>>> maximum = LastValue( HHV( m, r ) );
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Plot( m, "MACD", colorRed, styleOwnScale, minimum,
> >>>>>>>>>>>>>>>> maximum );
> >>>>>>>>>>>>>>>> Plot(0, "", colorBlack, styleOwnScale, minimum,
> >>>>>>>>>>>>>>>> maximum);
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Sat, Jun 27, 2009 at 11:16 AM, Dennis Brown see3d@
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Maybe not...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Through this discussion, the problem has been reduced
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>> aligning
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> min/max range of a MACD styleOwnScale plot to another
> >>>>>>>>>>>>>>>> zero
> >>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>> styleOwnScale plot statement. Therefore, the only way
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> do
> >>>>>>>>>>>> this is
> >>>>>>>>>>>>>>>> to find the min/max values of the MA CD function in the
> >>>>>>>>>>>> visible bars
> >>>>>>>>>>>>>>>> range and use those numbers in both plot statements, or
> >>>>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>> MACD
> >>>>>>>>>>>>>>>> range symmetrical and then the zero line statement
> >>>>>>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>> any
> >>>>>>>>>>>>>>>> symmetrical range.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am happy with my dual colored plot line at this
> >>>>>>>>>>>>>>>> point.
> >>>>>>>>>>>> However, to
> >>>>>>>>>>>>>>>> complete the original idea, I could use a simple loop
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> find
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>> min/
> >>>>>>>>>>>>>>>> max numbers of the MACD, but I am now wondering if
> >>>>>>>>>>>>>>>> there
> >>>>>>>>>>>>>>>> is a
> >>>>>>>>>>>>>> "faster"
> >>>>>>>>>>>>>>>> execution way using array logic instead?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It seems like a waist of time to create an array of the
> >>>>>>>>>>>>>>>> Min/
> >>>>>>>>>>>> Max over
> >>>>>>>>>>>>>>>> that range for all bars, then just use the last
> >>>>>>>>>>>>>>>> value. I
> >>>>>>>>>>>>>>>> use
> >>>>>>>>>>>> loops
> >>>>>>>>>>>>>>>> when I only want a single number result related to the
> >>>>>>>>>>>>>>>> Min/
> >>>>>>>>>>>>>>>> Max
> >>>>>>>>>>>> value
> >>>>>>>>>>>>>>>> over the last n bars only (like the v isible bar
> >>>>>>>>>>>>>>>> range).
> >>>>>>>>>>>>>>>> Am I
> >>>>>>>>>>>> missing
> >>>>>>>>>>>>>>>> an opportunity to approach this in a more efficient
> >>>>>>>>>>>>>>>> way?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> BR,
> >>>>>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Jun 27, 2009, at 9:06 AM, gmorlosky wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> maybe....
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> IF ( MACDline == Signalline) // histogram value equals
> >>>>>>>>>>>>>>>>> zero
> >>>>>>>>>>>>>>>>> X = lastvalue(MACDline-Signalline);
> >>>>>>>>>>>>>>>>> Plot (X,"", colorblack);
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown see3d@
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yes, I have it set to 100%. The absolute values of
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>> indicator
> >>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>> vary wildly, depending on the price and volatility of
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>> stock.
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>> & gt;> plot ES, so the values are quite large at times.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> BR,
> >>>>>>>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Jun 26, 2009, at 5:58 PM, monitorit wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If that's all you needed, the color change would be
> >>>>>>>>>>>>>>>>>>> best.
> >>>>>>>>>>>> But, I
> >>>>>>>>>>>>>>>>>>> think the solution I suggested would work... you
> >>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>> plot/
> >>>>>>>>>>>>>>>>>>> see value very high or low just within a section
> >>>>>>>>>>>>>>>>>>> defined by
> >>>>>>>>>>>>>>>> pane*1/
> >>>>>>>>>>>>>>>>>>> minvalue [at least it has for me]. BTW, presently
> >>>>>>>>>>>>>>>>>>> what is
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> upper
> >>>>>>>>>>>>>>>>>>> and lower bounds of the MACD in relationship to the
> >>>>>>>>>>>>>>>>>>> height
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> pane? Is it 100% of the pane height?
> >>>>>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>>> ;>
> >>>>>>>>>>>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown
> >>>>>>>>>>>>>>>>>>> <see3d@>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Dan,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This is what I usually do for indicators when I
> >>>>>>>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>> range
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> values. However, MACD is an unbounded indicator,
> >>>>>>>>>>>>>>>>>>>> so I
> >>>>>>>>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>>>>> large the values are. It is only the zero crossings
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>> relative
> >>>>>>>>>>>>>>>>>>>> peaks that are useful info here.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I just thought there would be some simple
> >>>>>>>>>>>>>>>>>>>> shortcut to
> >>>>>>>>>>>> actually
> >>>>>>>>>>>>>>>>>>>> scanning the visible bars for the min/max values to
> >>>>>>>>>>>>>>>>>>>> use in
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> plot
> >>>>>>>>>>>>>>>>>>>> statemen ts. I think I will just switch colors of
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> MACD
> >>>>>>>>>>>> from
> >>>>>>>>>>>>>>>> red
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> green if it is above or below zero instead of
> >>>>>>>>>>>>>>>>>>>> resorting to
> >>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>>>>>> loop.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Jun 26, 2009, at 4:40 PM, monitorit wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Dennis,
> >>>>>>>>>>>>>>>>>>>>> Hi. You might try this- Place a value in minvalue
> >>>>>>>>>>>>>>>>>>>>> section
> >>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>> none
> >>>>>>>>>>>>>>>>>>>>> in maxvalue section [I think maybe a value like 2
> >>>>>>>>>>>>>>>>>>>>> equates
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> 1/2
> >>>>>>>>>>>>>>>>>>>>> pan e height] of your MACD and zero plot
> >>>>>>>>>>>>>>>>>>>>> statements.
> >>>>>>>>>>>>>>>>>>>>> Also,styleNoRescale in the zero plot statement.
> >>>>>>>>>>>>>>>>>>>>> This
> >>>>>>>>>>>>>>>>>>>>> worked
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>> me
> >>>>>>>>>>>>>>>>>>>>> when I wanted to plot a histogram and a dot on the
> >>>>>>>>>>>>>>>>>>>>> top of
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> histogram. Not sure if it works with a line. If it
> >>>>>>>>>>>>>>>>>>>>> doesn't,
> >>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>> could try plotohlc with H=max(0,my#) and
> >>>>>>>>>>>>>>>>>>>>> L=min(0,my#).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown
> >>>>>>>>>>>>>>>>>>>>> <see3d@>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> This must be simple, but my AFL brain is fried
> >>>>>>>>>>>>>>>>>>>>>> today. I
> >>>>>>>>>>>> have
> >>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>> MACD
> >>>>>>>>>>>>>>>>>>>>>> plot on top of my main price chart, and I want to
> >>>>>>>>>>>>>>>>>>>>>> plot a
> >>>>>>>>>>>> zero
> >>>>>>>>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>>>>>>>> over it. It is plotted as StyleOwnScale of
> >>>>>>>>>>>>>>>>>>>>>> course. I
> >>>>>>>>>>>>>>>>>>>>>> can't
> >>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>>> StyleLeftAxis because I am using it for something
> >>>>>>>>>>>>>>>>>>>>>> else. I
> >>>>>>>>>>>>>>>>>>>>>> guess I
> >>>>>>>>>>>>>>>>>>>>>> could do something to figure out where the
> >>>>>>>>>>>>>>>>>>>>>> visible
> >>>>>>>>>>>>>>>>>>>>>> high
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>> low
> >>>>>>>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>>> of the MACD are, but it seems like it should be
> >>>>>>>>>>>>>>>>>>>>>> easier
> >>>>>>>>>>>> than
> >>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> TIA,
> >>>>>>>>>>>>>>>>>>>>>> Dennis
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ------------------------------------
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>>>>>>>>>>>>>> This group is for the discussion between users
> >>>>>>>>>>>>>>>>>>>>> only.
> >>>>>>>>>>>>>>>>>>>>> This is *NOT* technical support channel.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly
> >>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER
> >>>>>>>>>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>> http://www.amibroker.com/feedback/
> >>>>>>>>>>>>>>>>>>>>> (submissions sent via other channels won't be
> >>>>>>>>>>>>>>>>>>>>> considered)
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news
> >>>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>> check
> >>>>>>>>>>>>>>>> DEVLOG:
> >>>>>>>>>>>>>>>>>>>>> http://www.amibroker.com/devlog/
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yahoo! Groups Links
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ------------------------------------
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>>>>>>>>>>>> This group is for the discussion between users only.
> >>>>>>>>>>>>>> ;>>>>> This is *NOT* technical support channel.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>>>>>>>>>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>>>>>>>>>>>>>>> http://www.amibroker.com/feedback/
> >>>>>>>>>>>>>>>>>>> (submissions sent via other channels won't be
> >>>>>>>>>>>>>>>>>>> considered)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always
> >>>>>>>>>>>>>>>>>>> check
> >>>>>>>>>>>>>> DEVLOG:
> >>>>>>>>>>>>>>>>>>> http://www.amibroker.com/devlog/
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yahoo! Groups Links
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> & gt;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ------------------------------------
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>>>>>>>>>> This group is for the discussion between users only.
> >>>>>>>>>>>>>>>>> This is *NOT* technical support channel.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>>>>>>>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>>>>>>>>>>>>> http://www.amibroker.com/feedback/
> >>>>>>>>>>>>>>>>> (submissions sent via other channels won't be
> >>>>>>>>>>>>>>>>> considered)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always
> >>>>>>>>>>>>>>>>> check
> >>>>>>>>>>>> DEVLOG:
> >>>>>>>>>>>>>>>>> http://www.amibroker.com/devlog/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yahoo! Groups Links
> >>>>>>>>>>>> & gt; >>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ------------------------------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>>>>>>> This group is for the discussion between users only.
> >>>>>>>>>>>>>> This is *NOT* technical support channel.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>>>>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>>>>>>>>>> http://www.amibroker.com/feedback/
> >>>>>>>>>>>>>> (submissions sent via other channels won't be considered)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check
> >>>>>>>>>>>>>> DEVLOG:
> >>>>>>>>>>>>>> http://www.amibroker.com/devlog/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yahoo! Groups Links
> >>>>>>>>>>>>>>
> >>>>>>>>>>>> & gt; >
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ------------------------------------
> >>>>>>>>>
> >>>>>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>>>>> This group is for the discussion between users only.
> >>>>>>>>> This is *NOT* technical support channel.
> >>>>>>>>>
> >>>>>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>>>>> SUPPORT {at} amibroker.com
> >>>>>>>>>
> >>>>>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>>>>> http://www.amibroker.com/feedback/
> >>>>>>>>> (submissions sent via other channels won't be considered)
> >>>>>>>>>
> >>>>>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check
> >>>>>>>>> DEVLOG:
> >>>>>>>>> http://www.amibroker.com/devlog/
> >>>>>>>>>
> >>>>>>>>> Yahoo! Groups Links
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------
> >>>>>>
> >>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>> This group is for the discussion between users only.
> >>>>>> This is *NOT* technical support channel.
> >>>>>>
> >>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>> SUPPORT {at} amibroker.com
> >>>>>>
> >>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>> http://www.amibroker.com/feedback/
> >>>>>> (submissions sent via other channels won't be considered)
> >>>>>>
> >>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> >>>>>> http://www.amibroker.com/devlog/
> >>>>>>
> >>>>>> Yahoo! Groups Links
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------------
> >>>>
> >>>> **** IMPORTANT PLEASE READ ****
> >>>> This group is for the discussion between users only.
> >>>> This is *NOT* technical support channel.
> >>>>
> >>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>> SUPPORT {at} amibroker.com
> >>>>
> >>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>> http://www.amibroker.com/feedback/
> >>>> (submissions sent via other channels won't be considered)
> >>>>
> >>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> >>>> http://www.amibroker.com/devlog/
> >>>>
> >>>> Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > **** IMPORTANT PLEASE READ ****
> > This group is for the discussion between users only.
> > This is *NOT* technical support channel.
> >
> > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > SUPPORT {at} amibroker.com
> >
> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > http://www.amibroker.com/feedback/
> > (submissions sent via other channels won't be considered)
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroker.com/devlog/
> >
> > Yahoo! Groups Links
> >
> >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> 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/
|