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 -----
From: Dennis Brown
To: [email protected]
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
