This may no longer be an issue ... but at one time X = 0 implied a variable which could not later be changed to an array ... with X = Cum (0), I'm sure of what I am getting ...
--- In [email protected], "tomy_frenchy" <[EMAIL PROTECTED]> wrote: > > Sure ! > I had understand before when you told me about that, but i am > understand more and more about this problem of precision for > multiple recursion with some power on them. > Solution if i am right : center the data on the time axis and > normalise their value the nearer from [-1;1]. > > Just one question, i have seen you use often iniatialize with "X=Cum > (0)" instead of "X=0". It seems the same (X=0, put 0 on all the bar > of X). It is because it react differently if QuickAFL is on/off > (SetBarsRequired) and with Cum(0) you are sure to fill all the bars ? > > > > > > --- In [email protected], "Fred" <ftonetti@> wrote: > > > > Possibly you understand now why in Gaussian Elimination I chose to > > arbitrarily set the midpoint along the x-axis to zero and keep the > > numbers along the scale in fairly tight range, and perform the > calcs > > in double precission ... yes ? > > > > --- In [email protected], "Tom Tom" <michel_b_g@> wrote: > > > > > > So after further investigation. > > > > > > > > > I code loop in VBS double. Result is not the same than SUM, nor > > FOR. > > > So SUM or FOR are not exact, but they act not the same in > > rounding. I thing > > > the arythmetic order to calculate is not the same in FOR and in > > SUM so > > > rounding are different, so result are different. > > > But one or other, result is not accurate. > > > If I want to stay in AFL and I had to choose between SUM and > FOR, > > wich one I > > > will go ? As they are both innacurate, SUM seems better ? > > > > > > > > > I test max/min number for AFL after reading the link from Paul : > > > http://en.wikipedia.org/wiki/IEEE_754 > > > > > > Code : > > > > > > ieee = -1e10; > > > _TRACE("IEEE:"+ ieee); // to show exponent > > > _TRACE("IEEE:"+ NumToStr(ieee,1.9) ); // to show innacurate digit > > > > > > And try after with : > > > ieee = 1e11; > > > > > > exponant should go from -126 to +127, but in our case : > > > ieee = 1e-10; -> result are infinite > > > ieee = 1e11; -> ok for direct trace, but with numtostr there is > > rounding and > > > do not use exponent notation > > > ieee = 1e39; -> result are infinite > > > > > > So my question, wy exponent go from -10 to 39 !? > > > And NumToStr(x,1.9), seems to send back rounding result. Cannot > it > > send back > > > with exponent notation and no rounding like direct _trace ? > > > > > > Second, accuracy seems 7 digit, but it should be 6 digit ? (max > > number from > > > the mantisse is 2^23 - 1 = 8388607, that give 7 number so six > > digit sure). > > > Try: ieee = 99999981 > > > 7th digit is ok. 8th digit is wrong. > > > > > > So AB use wich encoding (not IEEE_754 ?) and difference between > > direct > > > _trace and _trace with NumToStr come from NumToStr wich make > > rounding for > > > big exponent ? > > > > > > Cheers, > > > Mich. > > > > > > _________________________________________________________________ > > > Windows Live Messenger sur i-modeĀ : dialoguez avec vos amis > > depuis votre > > > mobile comme sur PC ! http://mobile.live.fr/messenger/bouygues/ > > > > > >
