You should better read CAREFULLY (if needed twice or three times) the document
you have
quoted http://en.wikipedia.org/wiki/IEEE_754
Specifically:
1.. The smallest non-zero positive and largest non-zero negative numbers
(represented by the denormalized value with all 0s in the Exp field and the
binary value 1 in the Fraction field) are
±2?149 ? ±1.4012985×10^?45
2.. The smallest non-zero positive and largest non-zero negative normalized
numbers (represented with the binary value 1 in the Exp field and 0 in the
Fraction field) are
±2?126 ? ±1.175494351×10^?38
3.. The largest finite positive and smallest finite negative numbers
(represented by the value with 254 in the Exp field and all 1s in the Fraction
field) are
±(2128 ? 2104) ? ±3.4028235×10^38
And IEEE single precision is industry standard when it comes to T/A programs
as pricing data usually have 4-5 significant digits at most so 3-4 orders of
magnitude
additional accuracy provided by single precision IEEE is perfectly enough.
Doubles are needed for astronomy or weather calculations not for easy stuff like
computation on stock/futures prices which you are going to display on
computer screen that is anyway limited to something like less than 2048 pixels
resolution
(that's only 3 and half significant digit accuracy)
If you really belive you have a problem that needs more then use DLL, JScript,
VBScript or
external ActiveX and stop wasting bandwidth on esoteric stuff.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "Tom Tom" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, November 16, 2006 8:14 PM
Subject: Re: [amibroker] Re: Digit precision on AB ?
> 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-modeT : dialoguez avec vos amis depuis votre
> mobile comme sur PC ! http://mobile.live.fr/messenger/bouygues/
>
>
>
> Please note that this group is for discussion between users only.
>
> To get support from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> Yahoo! Groups Links
>
>
>
>
>
>