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