|
PureBytes Links
Trading Reference Links
|
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
<*> 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/
|