|
Dennis,
I explained it many times:
1. You can not simply "KEEP" the array from previous
execution and reference it directy becase:
a) previous execution may be on different symbol/different
time frame/different zoom level leading
to DIFFERENT NUMBER OF ELEMENTS in the array and different
TIMESTAMPS of array bars.
2. Because of (1) the only way to implement "static array" is
to:
a) store not only array BUT also TIMESTAMPS with every
bar
b) during reading perform timestamp checking and
synchronization so referenced array data is aligned
with current execution data
If those two were not implemented you would NOT be able
to use "static arrays" at all.
3. Functionality already exists
a) Point 2a - storing arrays with timestamps is exactly what
AddToComposite ALREADY DOES
b) Point 2b - reading arrays with timestamps and aligning is
exactly what Foreign ALREADY DOES
4. Implementing dedicated "static" array functions
would
a) give NO SPEED ADVANTAGE over
AddToComposite/Foreign
b) give only "the impression" that it is something else and
"faster" than ATC/Foreign while it would
be FALSE impression.
Summary:
a) functionality already exists
b) no speed advantage over existing functionality
So here are the functions you are asking for:
function StaticVarArraySet( Varname, array )
{
AddToComposite( array, "~SA_"+VarName, "C", atcFlagDefaults | atcFlagEnableInBacktest |
atcFlagEnableInExplore | atcFlagEnableInIndicator |
atcFlagEnableInPortfolio );
}
function StaticVarArrayGet( VarName
);
{
return Foreign(
"~SA_"+VarName,
"C" );
}
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
Sent: Saturday, August 04, 2007 5:26
AM
Subject: [amibroker] Second thoughts on
Static arrays
Hi,
The more I have thought about static arrays for my AFL needs, the more I
see that what I am looking for is a quite
limited implementation.
Static arrays would have low overhead and give the speed needed just
like regular arrays. The primary need is to avoid re-computing
complex things all the time that only need to be computed under certain
conditions or perhaps once per new bar. This allows far richer AFLs to
be developed for real time trading, while improving the responsiveness of the
UI interaction under heavy compute conditions. The life of a static
array is fleeting.
Static arrays are not permanent like ATC, and do not
have the big overhead. Static arrays as I envision them, would have to
be updated via the user AFL program whenever a change in environment caused
the data to become invalid --like changing the symbol or the timeframe --or
even adding a new bar (which changes the array size). Having static
arrays like this would allow breaking the AFL into two parts --the fast part
that needs to run for every second, and the part that needs to run once per
compressed timeframe, volume, or range bar.
I am sure there are technical issues involved, or TJ would have already
provided them since they are so useful for speeding up AFL. First rule of
making programs fast is pre-compute everything possible and not inside a
loop. AFL is one big loop.
Perhaps what I am looking for are not technically
"static" arrays in the normal sense. Maybe I need to call them by a
different name for the suggestion box. Perhaps there is an even easier
way to address this need with a new AFL syntax: keep(myArray);
Comments
anyone?
Dennis Brown
__._,_.___
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
![]()
SPONSORED LINKS
__,_._,___
|