Thanks TJ. I didn't know of the Osaka plugin's existence. Thanks for making me aware.
--- In [email protected], "Tomasz Janeczko" <gro...@...> 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_z...@...> > To: <[email protected]> > 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 [email protected], "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 [email protected], "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 [email protected], 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: [email protected] > > > > > 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: [email protected] [mailto:[email protected]] > > > > > On Behalf Of Tomasz Janeczko > > > > > Sent: Friday, March 06, 2009 6:59 AM > > > > > To: [email protected] > > > > > 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 >
