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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
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
>>>
>>>
>>>
>>
>>
>>
>>
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
>
>
>