Tomasz,
Yes, I suspected it might be the case that only
pointers were being
copied for internal arrays. That is why I tried both in my
code.
for the read mode:
myArray = C;
and for the write
mode:
myArray = C + i; (i instead of 1 just in case you did
some
optimizing with
constants)
At the resolution of my results, the slowest results
for either case
were
between 1ms and 2ms.
This means that the overhead of running the
short AFL code shown was
dominating the execution time and the array processing time
was not
even significant
enough to noticeably affect the results. So in
reality, the array processing
is likely faster than I claimed.
That is also why I also said that
"static arrays" would would be very
fast even if they take 10 times as long to process as
internal arrays.
I was astounded at the efficiency of your code
for the internal
arrays.
You have done a very good job.
Best regards,
Dennis
Brown
On Aug 6, 2007, at 6:43 AM, Tomasz Janeczko
wrote:
> Dennis,
>
> This is NOT surprising,
because internal array does NOT use memory
> copy at
all!
>
> Internal arrays are so fast because referencing
them does nothing
>
except
> referncing via pointer (4 bytes always, regardless of
how long is
> the
array),
> while Foreign has to actually COPY memory (create new
array).
>
> So if you do assignment like this:
>
myArray = C;
>
> It effectivelly copies only 4 bytes (the
pointer) and increases
> "reference counter".
> This is what makes it
hyper-fast.
>
> But... as soon as you create NEW array,
say by doing this:
>
> myArray = C + 1;
>
>
Then timing would be much worse because of requried memory
copy.
> Testing this would give you true estimate of how fast
"static
> arrays"
could be.
>
> Best regards,
> Tomasz
Janeczko
> amibroker.com
> ----- Original Message
-----
> From: "Dennis Brown" <see3d@xxxxxxxxcom>
>
To: <amibroker@xxxxxxxxxps.com>
>
Sent: Monday, August 06, 2007 5:03 AM
> Subject: Re: [amibroker]
Re: Second thoughts on Static arrays --ATC/
> Foreign
times
>
>
>> Tomasz,
>>
>> I
ran a timing test to see what the difference would be for using
the
>> ATC/Foreign functions vs internal arrays with
practical values. I
>> selected an array size of 2000 and
generated 100 uniqueATC symbols.
>> Here are the AFL
execution times on my machine:
>>
>> ATC Write:
780ms
>> Foreign Read: 310ms
>> Internal arrays:
1ms
>>
>> This is compared to an ATC time of 23000ms
before I added the
>> SetBarsRequired(2000,0) at
the END of the AFL --a 30x improvement
>> because there are
about 40K bars in the 5 second database.
>>
>> So
the bottom line is that internal arrays seem to be at least
300
>> times as fast as ATC/Foreign.
>> The
potential improvements in speed seem very significant --even
if
>> static arrays as proposed were 10 times as slow as
internal arrays.
>> Perhaps it would be possible to just add
another mode to ATC/Foreign
>> that bypassed most overhead
for fast static arrays.
>>
>> Regardless of what you
decide to do though, the 30x improvement using
>>
SetBarsRequired(2000,0) at the END is enough to make it
worthwhile
>> for me to save some of my more time consuming
arrays between AFL
>> passes using ATC/Foreign to help with
the UI responsiveness.
>>
>> If I had another 30x
improvement in "static" array speed (which seems
>> quite
possible), I would save a lot more results and gain
>>
significantly more speed. In either case I believe I can now
move
>> forward from the first problem set and it only leaves
the second
>> problem set to enable me to begin trading this
system.
>>
>> Here is the simple AFL I used for the
test. I just turned on the AFL
>> chart timing for the
results.
>>
>> Thank you,
>> Dennis
Brown
>>
>> function
StaticArraySet(VarName,array){AddToComposite
>>
(array ,"~SA_"+VarName ,"C",atcFlagEnableInIndicator|
>>
atcFlagDefaults);}
>> function
StaticArrayGet(VarName){return
Foreign("~SA_"+VarName,"C");}
>>
>>
TestName = ParamStr("Test Name", "Test");
>> Cycles =
Param("Cycles",1,1,100,1);
>> UseATC =
ParamToggle("ATC mode","No|Yes",0);
>>
Writemode = ParamToggle("R/W
mode","Read|Write",1);
>>
>>
for(i=0;i<Cycles;i++)
>> {
>>
if(UseATC &
Writemode){StaticArraySet(TestName+i,C);}
>>
if(UseATC & NOT Writemode){myArray =
StaticArrayGet(TestName+i);}
>> if(NOT
UseATC & Writemode){myArray = C+i;}
>> if(NOT UseATC
& NOT Writemode){myArray = C;}
>> }
>>
SetBarsRequired(2000,0);
>>
>> On Aug 5,
2007, at 5:38 PM, Dennis Brown wrote:
>>
>>>
Tomasz and Daniel,
>>>
>>> Excellent points
about the advantages of ATC vs hidden memory
>>>
arrays.
>>>
>>> On the other side, when the
purpose of the hidden arrays is just to
>>> hold a
temporary array value between AFL passes that have a
short
>>> life span of perhaps a minute, and if you are
creating dozens of
>>> them, not having a "file system"
copy of data to read is of no more
>>> consequence than
not having a filesystem copy of any other AFL
>>>
array
>>> that is destroyed every pass. There could be
some debug value as
>>> confirmation that you are actually
creating them.
>>>
>>> With the memory only
"hidden" arrays, there might need to be a
>>>
simple
>>> way to "flush" all the saved arrays for a
"pane" from memory, either
>>> as a logical and automatic
consequence of AB, and/or via a single
>>> explicit AFL
command.
>>>
>>> The purpose of the proposal
is to speed up AFL by saving results
>>> that
>>> do not need to be
recalculated. ATC/Foreign have all the required
>>>
functionality to do this. With the hint by Tomasz (thank you)
about
>>> SetBarsRequired() at the END of the
AFL, part of the speed problems
>>> is solved. The only
reason to do a more limited version of ATC/
>>> Foreign
functionality (in some form) is to cut down on the
extra
>>> overhead to get the maximum speed improvement.
It is only worth
>>> doing if it can be done in a way that
will make the this
>>> functionality at least twice as
fast as regular ATC/Foreign. I need
>>> to test that
actual difference in generating and reading a normal
>>>
array and ATC/Foreign now to see how much could be gained. I
will
>>> report it soon.
>>>
>>>
Best regards,
>>> Dennis
Brown
>>>
>>>
>>>>
Hello,
>>>>
>>>> Foreign() is hand
optimized and generally very fast - generally
>>>>
speaking it's speed is
>>>> 70%..80% of memcpy() so I
am afraid "signatures" would not give any
>>>>
advantage considering
>>>> the fact that you need to
add special bookkeeping for
them.
>>>>
>>>> And your comment
regarding "hidden" nature of static variables is
>>>>
very true and that
>>>> is one of my
concerns.
>>>>
>>>> Best
regards,
>>>> Tomasz Janeczko
>>>>
amibroker.com
>>>> ----- Original Message
-----
>>>> From: "liberte721" <daniel.laliberte@gmail.com>
>>>>
To: <amibroker@xxxxxxxxxps.com>
>>>>
Sent: Sunday, August 05, 2007 4:36 PM
>>>> Subject:
[amibroker] Re: Second thoughts on Static arrays
--whole
>>>> problem
set
>>>>
>>>>
>>>>>
Tomasz,
>>>>>
>>>>> Thanks for
your reply and explanation. I have a couple other
>>>>>
ideas,
>>>>> and then I'll resume my usual silence.
:)
>>>>>
>>>>> The use of Foreign
to import an array might be optimized by a
>>>>>
quick
>>>>> comparison of the "signature" of the
array with that of the
>>>>> current
>>>>>
symbol. If they are identical, then no translation would
be
>>>>> necessary. By the "signature", I mean
something like a
>>>>> combination
of
>>>>> the barcount, date/time range and
timeframe, but since internal
>>>>> bars
>>>>> might be
missing, there should be a way to normalize the data
and
>>>>> mark
>>>>> it as
normalized. This might be more complex than it is
worth.
>>>>>
>>>>> The additional
"symbol" entries that ATC creates provide one
other
>>>>> advantage for users - these symbols can
be viewed or removed
>>>>>
manually.
>>>>> In contrast, runtime memory would
tend to fill up with invisible
>>>>> static arrays
requiring some other way to view and remove
them.
>>>>>
>>>>> Daniel
LaLiberte
>>>>>
>>>>>
>>>>>
--- In amibroker@xxxxxxxxxps.com,
"Tomasz Janeczko" <groups@xxx>
>>>>>
wrote:
>>>>>>
>>>>>>
Daniel,
>>>>>>
>>>>>> ATC
are NOT saved to disk unless cache needs to be flushed to
the
>>>>>> disk,
>>>>>> so
disk access has nothing to do with the
problem.
>>>>>>
>>>>>> There
are two areas that affect speed
>>>>>> 1) the
most important - ATC by default requires ALL bars to be
>>>>>>
used
>>>>>> so your formula is not executed in
QuickAFL mode
>>>>>> 2) Foreign needs to be done
to sychronize length/date stamps with
>>>>>
currently selected
symbol
>>>>>>
>>>>>> First
point can be easily resolved by adding
>>>>>>
SetBarsRequired at the END of the formula.
>>>>>>
Doing so, overrides any automatically calculated bar
requirements
>>>>>>
and
>>>>>> you will be able to shorten the number
of bars used and turn on
>>>>>
QuickAFL
>>>>>> even if ATC is
used.
>>>>>>
>>>>>> For
example adding
>>>>>> SetBarsRequired( 1000, 0
);
>>>>>> at the end will make that the formula
will require 1000 prior
>>>>>> bars
>>>>> and 0
future bars.
>>>>>>
>>>>>>
This should give large boost in speed if you are using
many
>>>>> thousands of
bars.
>>>>>>
>>>>>> Second
point is unevitable - see my previous
response.
>>>>>>
>>>>>> Best
regards,
>>>>>> Tomasz
Janeczko
>>>>>>
amibroker.com
>>>>>> ----- Original Message
-----
>>>>>> From: "liberte721"
<daniel.laliberte@...>
>>>>>>
To: <amibroker@xxxxxxxxxps.com>
>>>>>>
Sent: Sunday, August 05, 2007 8:09 AM
>>>>>>
Subject: [amibroker] Re: Second thoughts on Static arrays
--whole
>>>>> problem
set
>>>>>>
>>>>>>
>>>>>>>
Dennis,
>>>>>>>
>>>>>>>
I believe what you are asking for is different from the ATC
and
>>>>>>> Foreign functionality since you do
not want the persistent disk
>>>>>>> storage
that ATC provides. I think that point might have
been
>>>>>>>
missed
>>>>>>> in previous discussions. You
said:
>>>>>>>
>>>>>>>
"Because AFL is so fast working with arrays, It seems that
it
>>>>>>>
should
>>>>>>> be possible to just save an
array in memory in a high speed way,
>>>>>>>
then
>>>>>>> recall it to repopulate the array
instead of recalculate the
>>>>>>> array
if
>>>>>>> the AFL determines that the data
would not have changed since
>>>>>>> the
last
>>>>>>>
pass."
>>>>>>>
>>>>>>>
So you want in-memory arrays that continue to exist outside of
a
>>>>>>> single AFL script execution, but are
not persistent to disk. In
>>>>>>>
other
>>>>>>> words, if you close the AB
session and reopen, then you do not
>>>>>>>
expect
>>>>>>> your static arrays to have
survived. I think the term "static
>>>>>>>
arrays"
>>>>>>> is appropriate, analogous to
"static variables" that are also
>>>>>>>
not
>>>>>>> persistent. I'd be happier if
static variables also could just
>>>>>>>
store
>>>>>>> arrays as well as non-array
values.
>>>>>>>
>>>>>>>
It does seem that this form of static array memory should
be
>>>>>>> nearly
as
>>>>>>> fast as the temporary arrays that
live only within a single
>>>>>>>
script
>>>>>>> execution. They should merely
occupy a different part of the AB
>>>>>>>
memory space. I agree this would be very valuable for me
as
>>>>>>>
well,
>>>>>>> provided they were
fast.
>>>>>>>
>>>>>>>
Maybe ATC and Foreign functions effectively work this way by
not
>>>>>>> saving to disk unless you actually
save them explicitly (or
>>>>>>>
implicitly
>>>>>>> if you enable that). If so,
then it is not clear where the time
>>>>>>>
goes.
>>>>>>> Maybe there is a way to optimize
the use of these arrays to
>>>>>>>
avoid
>>>>>>> time-frame translation, for
example.
>>>>>>>
>>>>>>>
Daniel
LaLiberte
>>>>>>>
>>>>>>>
--- In amibroker@xxxxxxxxxps.com,
Dennis Brown <see3d@>
wrote:
>>>>>>>>
>>>>>>>>
Tomasz,
>>>>>>>>
>>>>>>>>
First let me thank you for your patients in explaining this
one
>>>>> more
>>>>>>>>
time. It makes a very good post for the benefit of
others.
>>>>>>>> Yes, I am aware of
everything you explained because you had
>>>>>
explained
>>>>>>>> it before and I listened
and tried out the
ideas.
>>>>>>>>
>>>>>>>>
I sent you a direct email through support #39911 on May 16
for
>>>>> which
>>>>>>>>
I received no reply (and none was technically required). I
>>>>>>>>
will
>>>>>>>> quote
it:
>>>>>>>>
>>>>>>>>
"I am taking this subject off the yahoo board now because I
>>>>>>>>
don't
>>>>>>>> think anyone can help but
you.
>>>>>>>> It can go back on the board
when there is a solution that will
>>>>>>>>
work.
>>>>>>>>
>>>>>>>>
I took your advice and made all the changes you suggested
to
>>>>> speed
up
>>>>>>>> my
AFL.
>>>>>>>> The functionality of the AFL
is working nicely, behaving just
>>>>>>>>
as it
>>>>>>>>
should.
>>>>>>>>
>>>>>>>>
However, instead of running 10 times faster, now it runs
>>>>>>>> twice
as
>>>>>>>> slow as
before.
>>>>>>>>
>>>>>>>>
I have narrowed the problem down to the very thing that
was
>>>>>
supposed
>>>>>>>> to speed it
up.
>>>>>>>>
>>>>>>>>
1. When I use the ATC & Foreign functions the number of
bars
>>>>>>>> required goes from 3518, 0 to
1000000, 1000000.
>>>>>>>> This looks like
it turns off fast AFL and slows all
normal
>>>>>>>> processing by requiring all
the bars. I have 77,000 data bars
>>>>>>>>
total.
>>>>>>>> I do not know if this is
intentional or a
bug.
>>>>>>>>
>>>>>>>>
2. The ATC function is slow, but I only do it once per bar
(1
>>>>>
minute).
>>>>>>>>
>>>>>>>>
3. The foreign function which is done every time is slow
also
>>>>>>>> (relative to normal
arrays).
>>>>>>>> It takes .04 seconds each
and I need dozens to replace the
>>>>>>>>
missing
>>>>>>>> static array
functionality.
>>>>>>>> Perhaps this is
also due to the 1000000
bars.
>>>>>>>>
>>>>>>>>
Without being able to have persistent arrays that are as
>>>>>>>> fast
as
>>>>>>>> normal arrays I will not be
able to achieve my trading goals
>>>>>>>>
for
>>>>> very
>>>>>>>>
many years until computers speed up by 10x. That is the
>>>>>>>> same
as
>>>>>>>> never to me. I wish I could
just declare some variables to be
>>>>>>>>
Persistent or Static and be done with it. It is easy for me
to
>>>>> say,
>>>>>>>>
but perhaps it is not so easy for you to do. However, being
>>>>>>>>
able
>>>>> to
>>>>>>>>
successfully use the methods discussed on the board opens up
a
>>>>> lot of
>>>>>>>>
extra possibilities due to the extra speed possible with
AFL.
>>>>>>>>
>>>>>>>>
I appreciate any help you can give in this
matter."
>>>>>>>>
>>>>>>>>
As I want a workable solution to my problem and want to use
AB
>>>>> for my
>>>>>>>>
project (I would be trading this already using my AB system
>>>>>>>> if
I
>>>>> had
>>>>>>>> a
solution), I will state the fundamental problems I face
>>>>>>>>
clearly
>>>>>>>> together here (instead of
disjointed posts like before) and
>>>>>>>>
then
>>>>>>>> perhaps a solution might
occur to you or somebody else.
Please
>>>>>>>> forgive the length and
complexity of this
post.
>>>>>>>>
>>>>>>>>
Background:
>>>>>>>>
>>>>>>>>
My trading system is very simple in principle. AFL
>>>>>>>> calculates
a
>>>>>>>> complex indicator, I draw manual
trend lines, and I place
>>>>>>>>
manual
>>>>>>>> trades on a single stock or
ETF at a time. It is day trading,
>>>>>>>>
so I
>>>>>>>> only have a few seconds to
trigger my trade when the
conditions
>>>>>>>>
are
>>>>>>>> right. My AFL allows rapid
manual selection of different
>>>>>
timeframes
>>>>>>>> via a parameter, and
selects the proper volume bar
settings
>>>>>>>> dynamically for different
ETFs or stocks. The program
>>>>>
automatically
>>>>>>>> runs through many
timeframes to select trade trigger
>>>>>>>>
possibilities
>>>>>>>> for me to
consider.
>>>>>>>> 1. There is a heavy
compute environment --several seconds of
>>>>>>>>
AFL.
>>>>>>>> 2. The environment is highly
interactive --drawing trend lines.
>>>>>>>>
3. Seconds count for placing
trades.
>>>>>>>>
>>>>>>>>
First Problem
set:
>>>>>>>>
>>>>>>>>
Under heavy compute loads (when AFL time is greater than
>>>>>>>>
refresh
>>>>>>>> rate), AB stops responding
to the
UI.
>>>>>>>>
>>>>>>>>
Workarounds:
>>>>>>>>
>>>>>>>>
The only way I can get some UI functionality back is to set
the
>>>>>>>> refresh rate to one second
longer than the AFL compute time.
>>>>> Then
I
>>>>>>>> can get UI functionality back,
but with many delays.
>>>>>>>> I also have
a ParamToggle() to turn off most indicator
>>>>>>>>
processing
>>>>>
so
>>>>>>>> that I can interact with the UI
better at times (but I lose my
>>>>>>>>
indicator plot references).
>>>>>>>> This
is a partially effective workaround that I could limp
>>>>>>>>
along
>>>>>
with.
>>>>>>>>
>>>>>>>>
Requested
solution:
>>>>>>>>
>>>>>>>>
Realizing that the root problem is that the UI functions
>>>>>>>> only
run
>>>>> (or
>>>>>>>>
initiate) in between AFL passes, I looked for a way to do
less
>>>>>>>> processing on each pass. The
AFL load could be much less
>>>>>>>> most
of
>>>>> the
>>>>>>>>
time because I only need to calculate everything when a
new
>>>>>>>> bar
is
>>>>>>>>
added.
>>>>>>>> I thought of two
possibilities:
>>>>>>>>
>>>>>>>>
1. Ask for an AFL function that is essentially
DoUserInterface
>>>>>>>>
().
>>>>>>>> Then put AFL into an infinite
loop and put these commands at
>>>>>>>>
appropriate places. Since this is backwards from the way
>>>>>>>> the
AFL
>>>>>>>> appears to work, I did not
make this
suggestion.
>>>>>>>>
>>>>>>>>
2. Ask for arrays that keep their data between AFL passes.
I
>>>>> tried
>>>>>>>>
using ATC for this. It functioned like it was supposed to,
but
>>>>>>>>
was
>>>>>>>> too slow to be a practical
solution. I understand the reason
>>>>>>>>
they
>>>>>>>> are so slow, and that is
because they are a true static
>>>>>>>>
permanent
>>>>>>>> array. However, what I
wanted was only for a normal array
>>>>>>>> to
be
>>>>>>>> saved between passes. They only
need to be identified by which
>>>>>
pane
>>>>>>>> they are associated with
(could be part of the internal name).
>>>>>
They
>>>>>>>> are only valid between new
bars (same array size). Changes to
>>>>>>>>
symbol, timeframe, parameters, etc., can be detected in the
AFL
>>>>>>>>
and
>>>>>>>> the array updated. I know this
can be done, because I did
>>>>>>>> it
for
>>>>> the
>>>>>>>>
ATC version I wrote and everything worked perfectly (just
not
>>>>>>>> faster). Because AFL is so
fast working with arrays, It seems
>>>>>>>>
that
>>>>>>>> it should be possible to just
save an array in memory in a high
>>>>>
speed
>>>>>>>> way, then recall it to
repopulate the array instead of
>>>>>>>>
recalculate
>>>>>>>> the array if the AFL
determines that the data would not have
>>>>>
changed
>>>>>>>> since the last
pass.
>>>>>>>>
>>>>>>>>
There may be another possible solution that I have not
>>>>>>>> thought
of
>>>>> and
>>>>>>>> I
would love to hear
it.
>>>>>>>>
>>>>>>>>
Second Problem
set:
>>>>>>>>
>>>>>>>>
Because this is a realtime trading system, decisions have to
be
>>>>> made
>>>>>>>>
from raw data which contains bad ticks that may fool the
>>>>>>>>
system.
>>>>>>>> Volume bars are used in
the system, and must be able to change
>>>>>
volume
>>>>>>>> per bar on different AFL
passes.
>>>>>>>> Built-in timeframe or
volume settings do not allow the
>>>>> flexibility
to
>>>>>>>> address
these
>>>>>>>>
>>>>>>>>
Workarounds:
>>>>>>>>
>>>>>>>>
A tick database is too large to have enough history for
the
>>>>>>>> indicators. Running a database
of 5 seconds for a basic 1
>>>>>>>>
minute
>>>>> bar
>>>>>>>>
(or equivalent for volume bars) allows for reasonably
effective
>>>>>>>>
bad
>>>>>>>> tick removal and volume bar
generation. History can be just
>>>>>>>>
60K
>>>>>>>> bars. Bad ticks are removed
and volume bar settings are
>>>>>>>>
determined
>>>>>>>> using the 5 second
bars. Arrays are built up using
>>>>>
TimeFrameSet() to
>>>>>>>> get
the actual bars used for indicator calculations and
graph
>>>>>
plots.
>>>>>>>> This approach works really
well, however, there is one big
>>>>>>>>
problem
>>>>>>>> with
it.
>>>>>>>>
>>>>>>>>
Even though I can display all my price and indicators in
the
>>>>>>>> timeframe I desire, I can not
draw studies that align to that
>>>>>>>>
timeframe. All studies are drawn in the pane relative to
5
>>>>>>>>
second
>>>>>>>> bars. This workaround is
not acceptable for
trading.
>>>>>>>>
>>>>>>>>
Requested
solution:
>>>>>>>>
>>>>>>>>
#1117 Make an AFL way to set the timeframe of the drawing
>>>>>>>>
studies
>>>>> to
>>>>>>>>
match the OHLC array created by
TimeFrameSet().
>>>>>>>>
>>>>>>>>
Of course implementing this has a general benefit of giving
an
>>>>> almost
>>>>>>>>
infinite number of time/volume/range bars settings via AFL
and
>>>>>>>>
parameters.
>>>>>>>>
>>>>>>>>
Please consider the problems (not just proposed solutions)
and
>>>>> advise
>>>>>>>>
if other possibilities come to mind for
solutions.
>>>>>>>>
>>>>>>>>
Thank you very much for your patients and
consideration,
>>>>>>>>
>>>>>>>>
Dennis
Brown
>>>>>>>>
>>>>>>>>
>>>>>>>>
On Aug 4, 2007, at 6:16 AM, Tomasz Janeczko
wrote:
>>>>>>>>
>>>>>>>>>
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: amibroker@xxxxxxxxxps.com
>>>>>>>>>
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