|
PureBytes Links
Trading Reference Links
|
>The only use of "nosync" option would be storing data that is >unrelated to time.
> File-based persistency is available from AFL level by means of >AddToComposite.
Not for the 'nosync' data..... since ATC is time relative why would I use it to store data that is unrelated to time?
Inbuilt persistency of 'nosync' arrays would be a quick and easy way to value add what is not there already.
No need for middle of the road users to go to the Osaka plugin etc then.
I have barely heard of the Osaka plugin ... is it AB supported?
I am a computer layperson and not keen to install plugins from third party 'free' and unsupported sites ...especially if the owner is no longer around.
I thought I heard about problems with the Osaka plugin ... it is getting old isn't it?
There's a lot of overhead in an SQL database if users are only keeping a handful of 'nosync' arrays per database.
The most common way I have seen people store persistent arrays is to write them to a text file ... that is what I meant when I made speed comparisons and also 'SQL via ODBC' must be slower than saving an AB 'nosync' array already in memory.
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> File-based persistency is available from AFL level by means of AddToComposite.
> File-based persistent variables are also available via Osaka plugin. Also multi-dim tables are available from Osaka plugin.
> It comes with full source code so anyone having any desires in that direction can extend it in any way he/she likes.
> Also database persistency can be achieved by existing ODBC plugin.
>
> I don't have any plans to add 4th or 5th way to do exactly the same what is already available.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "brian_z111" <brian_z111@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Sunday, March 08, 2009 1:51 AM
> Subject: [amibroker] Re: AmiBroker 5.24.0 BETA released .Static array variables implemented!
>
>
> 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@> 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/
|