> BTW I think the trick there would be to use the first elements of >an array, > stored in the database, but just exclude them from >compression/expansion > operations... they could even appear in a >special category in the symbol > hierachy list
Another idea for the melting pot. The problem of barcount alignment, at different intervals, could be managed within AB by a type of pseudo compression (for nosync elements only), rather than excluding 'no sync' arrays from compression. example: - 1000 days of intraday normal price data with a 5 min base timeframe - 'no sync' data is written to the base timeframe array and saved there... data entry starts from barindex() == 0 and continues sequentially - potentially 1000 * 78 bars of extra data can be entered (assuming 6.5 hour day session only) - when data is compressed to, say, a daily timeframe 'no sync' data could be treated specially ... a psuedo compression would 'read' only the first 1000 bars, starting from barindex() == 0 ... this way the number of elements available would never overflow the barcount for the timeframe. Users need to know the limits of data storage, relative to the timeframe they want to use it in, for themselves, however if they do not manage it correctly nothing will crash and no errors would occur ... they just wouldn't be able to access any data beyond what relates to that timeframe. I suppose the option is always there for users to 'declare' the length of the nosync array OR for AB to require the timeframe to be specified in the arguments ... under the later arrangement AB could then apply a limit to the length. If the 'extra' data references bars in the middle of the time series then that could easily be taken care of by applying a relative adjustment factor to the 'nosync' bar index to shift the alignment of the extra data relative to the price data ... there shouldn't be any need to consider QuickAFL at all because the extra data array would take up its relative position and AFL or QuickAFL would use the bars it needs to as per usual. --- In [email protected], "brian_z111" <brian_z...@...> wrote: > > Tomasz, > > Re: 'nosync' arrays > > Please be gentle with me ... you know I only conduct computing thought > experiments and have never opened the bonnet on my computer, or read the OS > manual. > > Also, I am not teaching you how to suck eggs ... I don't know what is in your > mind ... I can only make an approximate guess based on your comms ... better > to speak up now, while it is in Beta, rather than be sorry later. > > > IMO 'no sync' arrays are not a trivial addition. > > By your own caveats one of the problems with staticvariables(arrays) is time > relativity, specifically compression to different intervals..... so when > users are free to create and reference staticvariable(arrays) unintended > consequences can occur. > > In some ways 'nosync' arrays are actually easier for the user to manage in > this regard ... the logic is simple enough in some cases that one assumes are > complicated at first. > > Example: > > - at the moment it is problematical to reference into lower timeframes from a > higher timeframe (assuming one has the lower timeframe database) > > - quite easy with 'no sync' arrays because even though they are not paired > with a time value they can still be relative in time if desired > > C1 = [10,11,9,12];//the close of the 1600 bar in 5 min bars database > > For those four days of intraday data, compressed to daily view, the close is > 10,11,9,12 so time relativity is actually maintained by the barindex() of the > daily array referenced to the barindex() of the nosyncarray (on a one to one > basis). > > By this method any intraday value could be referenced, once per intraday > session, written to a nosync(array) subscript by subscript, and still > maintain relativity via the barindex() value in the higher timeframe == no > compression problems at all. > > The same can apply to 'dynamic nosync variables(arrays)': > > sym1 = [0.20,0,0.56,1.77]; > sym2 = [0.30,0.20,0.55,0]; > > > The values could be, say, dividends that are relative to daily bars, monthly > bars or whatever ... the user decides. > > The possibilities for intra-database analysis are on the big side. > > If they are persistent i.e. can be saved with the database, then that means > that extra data, like dividends, can be imported and used later ... this is > another fundamental trading tool that is not 'easy peasy' in AB at the moment. > > Values in a 'collection' of nosync arrays don't have to be of the same kind > either, as long as relativity is maintained to the barindex in another > timeframe: > > sym1divs = [0.20,0,0.56,1.77]; > sym1RTvalue = [10,11,9,12]; > > > I understand that their 'behaviour' would be different to ATC and the > database in general, which is why I started to discuss location and > management of them ... you know I am not having a go at you ... just being > inquisitive and canvassing the possibilities. > > > BTW I think the trick there would be to use the first elements of an array, > stored in the database, but just exclude them from compression/expansion > operations... they could even appear in a special category in the symbol > hierachy list ... unless of course you have other ideas, like a separate > global database i.e. global to other databases. > > IMO 'no sync' arrays would be a step forward for AB and an integral part of > it's growth ... worthy of more than an add on database etc. > > > > > > > > --- In [email protected], "Tomasz Janeczko" <groups@> wrote: > > > > It is not about global or local (i.e. scope), but about lifetime of > > variables. > > > > Static variables as far as scope is considered are global, > > however that is not the most important thing. > > > > The lifetime is where the main difference is. > > > > The lifetime of static variable is as long as program is running, i.e. they > > keep values > > between subsequent AFL execution, and you can read/write to them > > from to/from different formulas within same AmiBroker instance, while > > regular variables > > live only during single formula execution. > > Static variables do not however survive restart of application or do not > > work across > > different instances. > > > > AddToComposite is different because it actually stores values to the > > database > > so values do persist between reset and between instances. > > > > Best regards, > > Tomasz Janeczko > > amibroker.com > > ----- Original Message ----- > > From: "vlanschot" <vlanschot@> > > To: <[email protected]> > > Sent: Monday, March 09, 2009 1:10 PM > > Subject: [amibroker] Re: AmiBroker 5.24.0 BETA released > > > > > > > Tomasz, > > > > > > To clarify my understanding (and perhaps help others as well): > > > > > > 1) The upgrade of StaticVarSet/Get now allows arrays, previously only > > > numbers and strings. > > > 2) StaticVarSet allows one to store an array and then retrieve this via > > > StaticVarGet similar to > > > a) Foreign (ATC), EXCEPT that this works globally, > > > b) VarGet (VarSet), EXCEPT that this works locally only > > > > > > If this is correct, how "semi-global" are they stored: not only "in view" > > > for indicators, but also "once viewed" (i.e. updated) > > > per session? > > > > > > PS > > > > > > --- In [email protected], "Tomasz Janeczko" <groups@> wrote: > > >> > > >> Hello, > > >> > > >> Yes calculation of complex formula in one pane and passing to other panes > > >> is the simplest application. > > >> > > >> Similar thing is making "complex" indicator re-calculate not with every > > >> refresh, > > >> but say only once a minute. The following example shows how to calculate > > >> not more often than 5 seconds > > >> > > >> t = GetPerformanceCounter()/1000; > > >> > > >> diff = t - Nz( StaticVarGet("lastt") ); > > >> > > >> RecalcInterval = 5; // re-calculate ONLY every 5 seconds > > >> > > >> if( diff < RecalcInterval > > >> AND Name() == StaticVarGetText("lastname") ) > > >> { > > >> Plot( StaticVarGet("precomputedarray"), "PreComputedArray", colorRed > > >> ); > > >> } > > >> else > > >> { > > >> something = MA( C, 10 ); > > >> Plot( something, "FreshCalc", colorBlue ); > > >> > > >> StaticVarSet( "lastt", t ); > > >> StaticVarSet( "precomputedarray", something ); > > >> StaticVarSetText( "lastname", Name() ); > > >> > > >> } > > >> > > >> > > >> Different way of using it is for example, storing "best" portfolio > > >> equity and other > > >> array metrics in the custom backtester and dynamically displaying them > > >> during > > >> optimization (to watch "evolution" of best result) > > >> > > >> Another possibility is creation of composite indicators in a similar way > > >> as AddToComposite, but faster. > > >> > > >> > > >> Best regards, > > >> Tomasz Janeczko > > >> amibroker.com > > >> ----- Original Message ----- > > >> From: "Dennis Brown" <see3d@> > > >> To: <[email protected]> > > >> Sent: Saturday, March 07, 2009 4:14 AM > > >> Subject: Re: [amibroker] Re: AmiBroker 5.24.0 BETA released > > >> > > >> > > >> > There had been a lot of discussions in past posts about how static > > >> > array variables could be used. However, I think the one that is most > > >> > easily understood would be where you have two panes in a chart and you > > >> > calculate a complex AFL to get some array in the top chart. However, > > >> > you want to display an indicator in the lower pane that is derived > > >> > from that complex calculation. Instead of duplicating the AFL from > > >> > the top pane again in the lower pane, now the results from the top > > >> > pane can be saved in a static variable, and the AFL in the lower pane > > >> > can just use the array value in the same static variable. > > >> > > > >> > We have had the ability to pass single values between charts (or AFL > > >> > passes), but now we can do that with complete arrays. I am sure > > >> > others will find interesting things to do with static array variables > > >> > over time. > > >> > > > >> > Best regards, > > >> > Dennis > > >> > > > >> > > > >> > On Mar 6, 2009, at 8:06 PM, droskill wrote: > > >> > > > >> >> Very interesting - I'm wondering if someone could provide an simple > > >> >> example of how one might use the feature - I realize this is > > >> >> probably obvious to all of you - but I'd be curious to see what > > >> >> people are using them for. > > >> >> > > >> >> --- In [email protected], "brian_z111" <brian_z111@> wrote: > > >> >>> > > >> >>> Thankyou very much Tomasz. > > >> >>> > > >> >>> Another small addition that leverages a lot of possibilities. > > >> >>> > > >> >>> Again it was the end result of very good communication between you > > >> >>> and the forum. > > >> >>> > > >> >>> Thanks for looking after Natasha too. > > >> >>> > > >> >>> > > >> >>> --- In [email protected], "Tomasz Janeczko" <groups@> wrote: > > >> >>>> > > >> >>>> 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 > > >> >>>> > > >> >>> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> ------------------------------------ > > >> >> > > >> >> **** 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 > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > ------------------------------------ > > > > > > **** 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 > > > > > > > > > > > >
