|
PureBytes Links
Trading Reference Links
|
Brian,
Yes, AB actually executes the AFL code on the first pass with all bars
to figure out how many bars are needed. If the SBR comes as a last
statement, then it uses that number instead of the calculated one. It
was already suggested that if all array processing is skipped on the
first pass and only an SBR is executed, then it takes little time to
set the bar requirements.
BR,
Dennis
On Jun 30, 2009, at 9:07 PM, brian_z111 wrote:
> Another psuedo bump.
>
> Re does AB execute to 'decide' on how many bars to use or not?
>
> - some say that observed beavhiour answers yes (or are the
> observations incorrect)?
>
> - I am putting a tick on the QuickAFL/SetBarsRequired box (as it has
> been explained by Tomasz) ... reason == this is logical, practical
> and qualifies as a good generic solution (in my mind which is where
> I have to make my assessments).
>
> - once a smart decision, about the # bars required has been made by
> the compiler (if that is what happens) is it possible that this is
> enough and that this is the end of the allocation process?
>
> - what happens if SBR is 1000 and AB makes a smart allocation of
> 1030 bars worth of memory but then on the first exection of the code
> (for the first symbol) AB 'finds' that there are only 700 bars in
> the database ... how could AB find this out?
>
> Maybe it sets the allocation, executes one pass, and then compares
> the barcount to the SBR?
>
> .... maybe it does this for all symbols or maybe only the first?
>
> Who knows?
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> 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/
|