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