> Are you talking about writing static arrays to disk, using ATC >without > time stamping?
Yes. Yes, similar to ATC but different ... 'no sync' arrays would be non time relative. Dynamic arrays would allow 'arrays of arrays' like: C1 = [1,3,0,6,7];stores five elements C2 = [4,2,8];//stores three elements Since it is in beta Tomasz doesn't say if static arrays works, for all bars, in AA mode ... guess it must. Also, I presume we can use array subscripts to reference, say, the third element in C1 i.e. C1[2] If Tomasz does implement 'persistent arrays' then yes, it would be like a database and opens the possibility to pass an array to another database (if they are stored in a global AB area).... I guess users could toggle on/off local/global saving of persistent arrays? Saving static arrays, as binary files, would be much faster than sending to an SQL database I think? --- In [email protected], Dennis Brown <se...@...> wrote: > > 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 [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 > > > > > > >
