|
PureBytes Links
Trading Reference Links
|
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@xxx> 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
<*> 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/
|