[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [amibroker] Re: AmiBroker 5.24.0 BETA released .Static array variables implemented!



PureBytes Links

Trading Reference Links

Brian,

I am not sure I follow what you are getting at, but just a few ideas:

Array of Arrays:
StaticVarSet("myMatrix"+Index+ChartKey, myArray);

I previously objected to this structure to build arrays because it  
could result in millions of individual static variables.  However, it  
is practical now with one dimension being a true array.  A large  
static matrix would exceed memory very quickly, so no point in going  
overboard.

Are you talking about writing static arrays to disk, using ATC without  
time stamping?

That would seem to be the logical extension to static arrays to gain  
persistence -- only write every once in a while the arrays to disk for  
speed.

I will admit that I have to be careful that there are enough bars  
loaded if I use AFL arrays for general (non time stamp related)  
purposes.  So far my use has been modest enough in dimensions to not  
be a problem.  If I needed a large dimension, I suppose I would have  
to run on a large dummy ticker in another chart, and pass the relevant  
data in non time stamped static arrays.  The key is to keep the  
processing tasks reasonable and modular.

Using a database is another possibility for storing lots of data on  
disk.

There are many ways to solve a problem if you have some basic low  
level functions to work with.

BR,
Dennis


On Mar 7, 2009, at 7:51 PM, brian_z111 wrote:

> Just an idea.
>
> If you do allow 'persistent arrays' then in a way they become custom  
> reserved variables ... so there is a need to manage them.... AB has  
> to know this at the start of each session?
>
> Would adding them at the head of the code, as, say a variation on  
> the includes theme be the way to go to manage this?
>
> The hard part of persisent arrays, for the user, would be  
> remembering them and the variables assigned to them, so there would  
> need to be some way of referencing all saved 'special reserved  
> variables' ... auto inclusion in an include(persistentvariables)  
> list might be a way to do that?
>
> Anyone else have an interest, or a comment, on this idea or other  
> other related ideas?
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>>
>> I think you are teasing me Tomasz :-)
>>
>> You must be thinking about adding array permits to VarSet etc so  
>> that we can read/write dynamic arrays, especially 'no sync' dynamic  
>> arrays.
>>
>> I think we are close to 'jagged arrays' and 'array of arrays'?
>>
>> So, soon we will have the power users Matrix Backtester toolkit  
>> hidden in the AFL .... I was 95% certain you would do it this way?
>>
>> Then I think you will have done everything possible to give Herman  
>> his Performance Indicators (ditto for those who work in the  
>> indicator pane a lot, like Dennis) .... all of the obtuse  
>> Performance Indicator and Matrix Backtester talk was useful  
>> afterall?  :-)
>>
>> I always liked that about you Tomasz .... I know you are great at  
>> playing snap and I work off that .... it's good fun ... you are a  
>> good sport.
>>
>>
>> I think we are bumping up against the limit... as shown by the N  
>> tick/timestamp limitations.... I predicted this because the  
>> overheads in managing the volume of data that is needed to calc  
>> indicators on the fly is pretty massive.
>>
>> Over time IT advances have a way of rubbing out limitations though.
>>
>> I can't help thinking that multicore is a huge asset in that  
>> regard ... some said it is only useful for huge number cruncing  
>> tasks like opt but I am not so sure about that.
>>
>> Say one core was busy massaging data on the fly while another was  
>> busy running other AB functions?
>>
>> Also, I think that not all ticks are created equal .... maybe some  
>> exchanges have finer grained timestamps than others ... appreciate  
>> thay you have to keep AB on the optimum point of the 'number of  
>> users versus benefits they gain' curve.
>>
>>
>>
>>
>>
>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
>>>
>>> Yes please,
>>>
>>> I think a 'no sync' flag would be a lot of 'bang for the buck'.
>>>
>>> Haven't downloaded and tried the beta yet but if they are not  
>>> persistent, between sessions and databases, that would be good ...  
>>> I would like to save a 'no sync' calculated array and reference it  
>>> again at a later date..... like an ~ATC in the sym list but not  
>>> necessarily visible.
>>>
>>> I think it is a way to bypass writing to files ... much quicker too.
>>>
>>>
>>>
>>> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
>>>>
>>>> Tomasz,
>>>>
>>>> I would welcome your idea of a "nosync" flag.
>>>>
>>>> Some of the uses I have for static arrays involve data that has no
>>>> relation to time stamps. Other uses are for saving temporary  
>>>> results
>>>> of calculations that are only needed once per parameter change on  
>>>> very
>>>> large arrays (200K) for special case backtesting.  The backtests  
>>>> are
>>>> on one security in indicator mode with real time feed off.  Speed  
>>>> is
>>>> important as it can take 20-30 seconds for one AFL pass today  
>>>> without
>>>> static arrays.  It will take a while before processor speeds  
>>>> increase
>>>> 30x.
>>>>
>>>> In these cases the extra overhead of matching time stamps would  
>>>> not be
>>>> needed, and in the first case might actually create problems.
>>>>
>>>> Best regards,
>>>> Dennis
>>>>
>>>> On Mar 7, 2009, at 4:08 AM, Tomasz Janeczko wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> In that case it will work because timestamps are in sync.
>>>>>
>>>>> In the future I may consider adding "nosync" flag, that will skip
>>>>> any timestamp matching logic for such simple scenarios.
>>>>>
>>>>> Generally speaking static array variables are designed to "do  
>>>>> their
>>>>> best" to synchronize to selected symbol even if there is no match.
>>>>>
>>>>> Best regards,
>>>>> Tomasz Janeczko
>>>>> amibroker.com
>>>>> ----- Original Message -----
>>>>> From: J. Biran
>>>>> To: amibroker@xxxxxxxxxxxxxxx
>>>>> Sent: Saturday, March 07, 2009 8:08 AM
>>>>> Subject: RE: [amibroker] AmiBroker 5.24.0 BETA released .Static
>>>>> array variables implemented!
>>>>>
>>>>> Hi TJ,
>>>>> Would you care to clarify comment d) below in the case of trying  
>>>>> to
>>>>> import output of one indicator from one pane to a second pane of
>>>>> same symbol and same interval when the interval is Range bars.
>>>>> Will it not work in that case?
>>>>>
>>>>> --
>>>>>
>>>>> Joseph Biran
>>>>> ____________________________________________
>>>>>
>>>>> From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx]
>>>>> On Behalf Of Tomasz Janeczko
>>>>> Sent: Friday, March 06, 2009 6:59 AM
>>>>> To: amibroker@xxxxxxxxxxxxxxx
>>>>> Subject: [amibroker] AmiBroker 5.24.0 BETA released •Static array
>>>>> variables implemented! (do NOT work well for tick/volume  
>>>>> intervals!)
>>>>>
>>>>> Hello,
>>>>>
>>>>> AmiBroker 5.24.0 BETA is released now:
>>>>> http://www.amibroker.com/devlog/2009/03/06/amibroker-5240-beta-released/
>>>>>
>>>>> This is somewhat special beta because it contains only one fix and
>>>>> introduces only one new feature: array static variables.
>>>>> I decided to release this feature "alone" because the static
>>>>> variable code has been completely rewritten, so in case of any
>>>>> issues, it would be easy to revert to 5.23.
>>>>>
>>>>> Best regards,
>>>>> Tomasz Janeczko
>>>>> amibroker.com
>>>>> d) static array variables do not work well for non-time based
>>>>> intervals (tick/n-volume/n-tick) because timestamps in those  
>>>>> intervals
>>>>> may not be unique (i.e. several bars may have same time stamp), so
>>>>> time synchronization is not reliable.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
>
> ------------------------------------
>
> **** IMPORTANT PLEASE READ ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> TO GET TECHNICAL SUPPORT send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> http://www.amibroker.com/feedback/
> (submissions sent via other channels won't be considered)
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> Yahoo! Groups Links
>
>
>



------------------------------------

**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.

TO GET TECHNICAL SUPPORT send an e-mail directly to 
SUPPORT {at} amibroker.com

TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)

For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/

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/