|
PureBytes Links
Trading Reference Links
|
Got it.
Bob
-----Original Message-----
From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx]On Behalf
Of Dennis Brown
Sent: Monday, May 14, 2007 7:49 AM
To: amibroker@xxxxxxxxxxxxxxx
Subject: Re: [amibroker] Methods for speeding up AFL code
Bob,
I was documenting the purpose of the flag not the purpose of the
assigned state (since I always use positive logic). I would do it at
declaration, but AFL does not declare locals so the initial
assignment is where I do it. It is just my personal convention. I
tend to put a lot more comments into my AFL than most. I will
reassess my comment strategy for the benefit of posting to others not
knowing how I do things for my self.
Dennis
On May 14, 2007, at 10:23 AM, Bob Jagow wrote:
> Right, Dennis.
> But what about the comments?
>
> firstflag=0; // this is [NOT] the first pass after startup
> Or firstflag=0; // first pass after startup?
>
> Likewise symbolchanged=0; // symbol changed since the last pass?
>
>
> -----Original Message-----
> From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx]
> On Behalf
> Of Dennis Brown
> Sent: Monday, May 14, 2007 6:55 AM
> To: amibroker@xxxxxxxxxxxxxxx
> Subject: Re: [amibroker] Methods for speeding up AFL code
>
> Bob,
>
> It is already. 1==true 0==false. Though I reset the flags more
> times than needed.
>
> if(firstflag){Say("first");}
> if(ParamsChanged){Say("parameter");}
> if(newBar){Say("new bar");}
> if(symbolchanged){Say("symbol");}
>
> Dennis
>
> On May 13, 2007, at 11:40 PM, Bob Jagow wrote:
>
>> Anyway to recode/rephrase your logic with False zero and True
>> nonzero?
>>
>>
>> -----Original Message-----
>> From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx]
>> On Behalf
>> Of Dennis Brown
>> Sent: Sunday, May 13, 2007 6:26 PM
>> To: amibroker@xxxxxxxxxxxxxxx
>> Subject: Re: [amibroker] Methods for speeding up AFL code
>>
>> Ok,
>>
>> I found a way --the light bulb glows brighter. the StaticVarGetText
>> ("name") does what I need. It does not make an error if the static
>> variable has not yet been defined, but returns null in that case.
>> With that capability, I can make everything happen the way I want. I
>> do not have to initialize the static var first before using it. That
>> makes it ideal to shadow a parameter value and detect if it has
>> changed. Of course numeric values have to be converted to strings
>> first to save them.
>>
>> Just to recap: I want to speed up my AFL a lot because I have some
>> very compute intensive stuff. My idea is to only compute some
>> indicators once per new bar to keep the AB UI running smoothly. To
>> do that I need to know when I have a new bar and other things that
>> would want a refresh of all indicators, like parameters changing,
>> symbol change, etc.
>>
>> The bit of test AFL below illustrates the principles of checking for
>> different changed conditions.
>>
>> I hope my posting the progression of my understanding process over
>> three days will be useful to others who encounter similar puzzles to
>> solve. It can also provide some clues as to how an index of the
>> documentation might have to be arranged to make it possible to find a
>> solution like this when one does not already know what they need to
>> know to solve the problem.
>>
>> I snipped out my detour posts below to make a logical flow of the
>> process for the benefit of later readers.
>> This post is a complete discussion and solution.
>>
>> Dennis
>>
>> firstflag=0; // this is the first pass after startup --if needed for
>> initializing regular static variables
>> if(StaticVarGetText("firstflag")==""){StaticVarSetText
>> ("firstflag","0");firstflag=1;}
>>
>> symbolchanged=0; //the symbol was changed since the last pass
>> if(Name()!=StaticVarGetText("name"))
>> {StaticVarSetText("name",Name()); symbolchanged=1;}
>>
>> newBar=0;
>> if(LastValue(BarIndex())!=StrToNum(StaticVarGetText("BarIndex")))
>> {StaticVarSetText("BarIndex",NumToStr(LastValue(BarIndex
>> ())));
>> newBar=1;}
>>
>> Paramschanged=0; //a parameter was changed since the last pass
>> //
>> _SECTION_BEGIN("Test Environment"); //sections here are just to
>> arrange parameters in UI groups
>> //
>> Daytrade= ParamToggle("Daytrade?","No|Yes",1);
>> if(Daytrade!=StrToNum(StaticVarGetText("Daytrade")))
>> {StaticVarSetText("Daytrade",NumToStr(Daytrade));
>> Paramschanged=1;}
>> //
>> plotEquity = ParamToggle("Plot Equity?","No|Yes",0);
>> if(firstflag){StaticVarSet("plotEquity",plotEquity );
>> Paramschanged=1;}
>> if(plotEquity !=StaticVarGet("plotEquity")){StaticVarSet
>> ("plotEquity",plotEquity ); Paramschanged=1;}
>> //
>> TradeBeg = 100*Param("| All Trading Begins HHMM", 930, 930, 1559,
>> 5); /* select trading start time with parameter window */
>> TradeEnd = 100*Param("| All Trading Ends HHMM", 1550, 930, 1559,
>> 5); /* select trading end time with parameter window */
>> TradeEnd2 = 100*Param("| New Trading Ends HHMM", 1550, 930, 1559,
>> 5); /* select trading end time with parameter window */
>> Params1 = _PARAM_VALUES(); // some params can be lumped together this
>> way
>> if(StaticVarGetText("params1") != _PARAM_VALUES()){StaticVarSetText
>> ("params1",_PARAM_VALUES());ParamsChanged=1;}
>> //
>> _SECTION_END();
>> //
>> //indicator processing
>> //
>> if(firstflag){Say("first");}
>> if(ParamsChanged){Say("parameter");Paramschanged=0;}
>> if(newBar){Say("new bar");newBar=0;}
>> if(symbolchanged){Say("symbol");symbolchanged=0;}
>> //
>> firstflag=0;
>>
>>
>>
>> On May 12, 2007, at 10:54 PM, Dennis Brown wrote:
>>> Tomasz,
>>>
>>> Now I understand why I have to use the ATC to make this work. Any
>>> normal array will become undefined after every AFL pass, so I need a
>>> static array variable to hold the value from the once per bar pass
>>> during all the in between passes. However, since the static array
>>> variable is not yet available, ATC can act as a static array
>>> variable
>>> filling this need.
>>>
>>> This whole concept of every pass of AFL starting over from an
>>> undefined state for all regular variables was one that escaped me
>>> until now. It did not really matter to me until now --when I wanted
>>> to preserve states across multiple passes. It is like the whole AFL
>>> is just a big procedure/function called once per pass. The static
>>> variables are to the main AFL like global variables are to a
>>> procedure/function. The light bulb!
>>>
>>> Thanks,
>>> Dennis
>>>
>>> On May 11, 2007, at 1:26 PM, Tomasz Janeczko wrote:
>>>
>>>> Hello,
>>>>
>>>> Then my advice is to use AddToComposite for computing intensive
>>>> task.
>>>>
>>>> lasttimenum = StaticVarGet("lasttimenum"); // if you want it chart-
>>>> specific you may add GetChartID() prefix/suffix
>>>>
>>>> if( ( Now( 4 ) - lasttimenum ) > 100 )
>>>> {
>>>> // one minute passed sincce last recalc
>>>>
>>>> .... // do computing intesive stuff here
>>>> result = .. .put your result array here
>>>>
>>>> AddToComposite( result, "~myresult", "x",
>>>> atcFlagEnableInIndicator | atcDefaults );
>>>> }
>>>>
>>>> // regular part that is executed all the time
>>>> result = Foreign("~myresult", "c" ); // this will retrieve values
>>>> of computing-intensive part calculated last time
>>>>
>>>>
>>>> Best regards,
>>>> Tomasz Janeczko
>>>> amibroker.com
>>>> ----- Original Message -----
>>>> From: "Dennis Brown" <see3d@xxxxxxxxxxx>
>>>> To: <amibroker@xxxxxxxxxxxxxxx>
>>>> Sent: Friday, May 11, 2007 6:52 PM
>>>> Subject: Re: [amibroker] Methods for speeding up AFL code
>>>>
>>>>
>>>>> Tomasz,
>>>>>
>>>>> Thank you for the helpful suggestions.
>>>>> My replies below are for everyones benefit.
>>>>>
>>>>> You have done a great job in making the AFL fast.
>>>>> Unfortunately, I still need to speed up my stuff more. I don't
>>>>> need
>>>>> to recompute ALL the historical bar related
>>>>> stuff for every second, just some simple stuff related to the last
>>>>> bars (1 min) real time price until the next bar opens.
>>>>>
>>>>> On May 11, 2007, at 10:30 AM, Tomasz Janeczko wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> You really need to take a look at the following and I guess you
>>>>>> will be able to rewrite
>>>>>> your formulas to run 10 times faster.
>>>>>>
>>>>>> 1. Use Tools->preferences->Misc "Display chart timing" to find
>>>>>> out
>>>>>> which formula takes
>>>>>> the most time to execute
>>>>>
>>>>> Most of the "generic" AFL runs in <.1 sec with my compute
>>>>> intensive
>>>>> functions turned off
>>>>> With my main function turned on (called 3 times for different
>>>>> Ehlers
>>>>> adaptive moving averages),
>>>>> it goes up by .25 sec per 1000 bars. I previously rewrote some of
>>>>> this function that I downloaded
>>>>> to speed it up by a factor of 5-10.
>>>>>
>>>>> I have another function that computes a result in 10 different
>>>>> settings to look for the best result.
>>>>> This of course takes a lot of time, and I have to limit the
>>>>> history
>>>>> in the AFL to keep it under a second.
>>>>> This is of course where all the time goes. Computing things in
>>>>> multiple settings (related to multiple time frames).
>>>>>
>>>>> Once the Total time goes over 1 sec, the UI does not respond well
>>>>> since the quotes come quicker than that.
>>>>>
>>>>>> 2. Use AFL editor "Check" function to find out how many past bars
>>>>>> given formula requires
>>>>>
>>>>> It reports 100,000 because that was put into the SetBarsRequired
>>>>> (SBR) to turn off fast AFL
>>>>> Fast AFL was causing problems with indicator lines not displaying
>>>>> intermittently previously.
>>>>> When I remove the SBR function, everything speeds up by 2x.
>>>>>
>>>>> I tried adding a ParamToggle to switch SBR from 100,000 to 0.
>>>>> However, once the SBR has
>>>>> been set to 100,000, it can not be turned back off from AFL. I
>>>>> have
>>>>> to recompile to reset it.
>>>>> Is there a way to reset the chart and SBR function while the
>>>>> AFL is
>>>>> running?
>>>>>
>>>>>> 3. To minimize number of charts required:
>>>>>> a) avoid Cum() function, instead use BarIndex() where possible
>>>>>
>>>>> I do not use this function.
>>>>>
>>>>>> b) use SetBarsRequired at the end of formula to force smaller
>>>>>> number of bars to be used (may affect some indicator values)
>>>>>
>>>>> Did not make a difference.
>>>>>
>>>>>> c) use VARIABLES as much as you can. If you need the same
>>>>>> function twice - call it ONCE and assign the result to variable
>>>>>> and use variable later instead of calling the same function
>>>>>> over
>>>>>> and over
>>>>>
>>>>> My normal practice --never calculate the same thing twice.
>>>>>
>>>>>> d) investigate what you are doing inside loops. When you put
>>>>>> very
>>>>>> time consuming stuff inside loop it will take N-times more
>>>>>> than the same stuff outside loop. Remove array functions from
>>>>>> inside the loops. For max speed loops should operate on array
>>>>>> ELEMENTS only.
>>>>>
>>>>> My normal practice --never calculate something in a loop that
>>>>> can be
>>>>> pre-computed outside the loop.
>>>>>
>>>>> I am a speed demon.
>>>>> I was programming real time machine control applications in
>>>>> machine
>>>>> language before the first microprocessor came out.
>>>>>
>>>>> Thank you for any further help you can suggest.
>>>>>
>>>>> Dennis
>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Tomasz Janeczko
>>>>>> amibroker.com
>>>>>> ----- Original Message -----
>>>>>> From: "Dennis Brown" <see3d@xxxxxxxxxxx>
>>>>>> To: <amibroker@xxxxxxxxxxxxxxx>
>>>>>> Sent: Friday, May 11, 2007 4:18 PM
>>>>>> Subject: [amibroker] Methods for speeding up AFL code
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have run out of processing speed on my 2GHz core duo trading
>>>>>>> machine. I do a lot of indicator computing and have bogged
>>>>>>> down AB
>>>>>>> to the point where it will no longer respond to the UI functions
>>>>>>> like
>>>>>>> cross hairs or switching timeframes when I click the buttons
>>>>>>> --or
>>>>>>> even being able to edit the AFL --and I still want to do 10
>>>>>>> times as
>>>>>>> much as I am doing now. The real time processing speed is
>>>>>>> inhibiting
>>>>>>> my creativity.
>>>>>>>
>>>>>>> So far I have put in a parameter that limits the number of bars
>>>>>>> that
>>>>>>> my most intensive calculations use. This helped, but not
>>>>>>> enough.
>>>>>>>
>>>>>>> My next idea is to only compute some functions that do not
>>>>>>> change
>>>>>>> often only once per bar complete.
>>>>>>>
>>>>>>> However, I still need to compute everything if I change a
>>>>>>> parameter,
>>>>>>> or switch stocks. To do this, I thought I might have to keep a
>>>>>>> copy
>>>>>>> of every parameter and compare each one to the value when it was
>>>>>>> last
>>>>>>> computed --and set a "needs updating" flag if any have changed.
>>>>>>>
>>>>>>> Has anyone else used this approach?
>>>>>>> Any hints about what I need to watch out for?
>>>>>>> Is there an easier way?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dennis
>>>>>>>
>
>
>
> Please note that this group is for discussion between users only.
>
> To get support from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> Yahoo! Groups Links
>
>
>
>
>
>
> Please note that this group is for discussion between users only.
>
> To get support from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> Yahoo! Groups Links
>
>
>
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
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/
|