|
PureBytes Links
Trading Reference Links
|
Hello,
When I'm creating a counter like this.
A1=-10 , A2=A1+0.01 ...
Excel doesn't calculate 0.0000 correctly in the 1001th cell.
It gives a result like " -1.6889E-13 ".
What's the matter ?
Excel or my P3 ?
TIA
Raf
-----Message d'origine-----
De: pierre.orphelin [SMTP:pierre.orphelin@xxxxxxxxxxxxxx]
Date: mardi, 24. juillet 2001 02:32
À: Bob Fulks
Cc: OmegaList
Objet: RE: Precision Errors
> -----Message d'origine-----
> De : Bob Fulks [mailto:bfulks@xxxxxxxxxxxx]
> Envoye : mardi 24 juillet 2001 01:23
> A : pierre.orphelin@xxxxxxxxxxxxxx
> Cc : OmegaList
> Objet : RE: Precision Errors
>
>
> I guess I have to reply to this since there seems to be a new
> misunderstanding.
>
Yes, if you want...
>
> At 9:28 PM +0200 7/23/01, pierre.orphelin wrote:
>
> >TS may display what it wants after digit 8 because it does not use
> >exponents, but the digits displayed after 8th digit is garbage, as
> >announced by the theory.
>
> Absolutely true. I'm glad you finally get it. As we have been saying,
> a single precision float has a resolution of about 7 decimal digits.
> As quoted in my message of 7/21/01:
>
> >>At 10:02 AM -0600 7/2/01, Gary Fritz wrote (Code List):
> >>
> >> >As background: single-precision floats have a 24-bit mantissa. That
> >> >is, they use 24 bits to represent the base of the number, and 8 bits
> >> >for the exponent. 24 bits can represent a signed value in the range
> >> >+/-8388608 or so, or not quite 7 digits of precision. You can
> >> >calculate the decimal (base 10) digits available with the formula
> >> >
> >> > (MatissaBits - 1) * log10(2)
> >> >
> >> >MantissaBits is 24, and we must subtract one bit for the sign of the
> >> >mantissa. That formula says there are 6.92 decimal digits available.
>
>
> >A float being a 32 bits BINARY number, you cannot expect a decimal
> >number with more than 10 digits ( 2^32), even if the magnitude of the
> >number is more than this ( magnitude being carried by the exponent
> >part that is coded in the 32 bit binary number, that in fact reduces
> >the precision mantissa part ).
>
> A float actually has a 24 bit mantissa and an 8 bit exponent.
> Precision is actually 2^24 = about 7 digits as explained above, but
> you are "close enough for Government work..."
>
Right.
My 2^32 example was a " demonstration par l'absurde", in french in Le texte.
>
> >So the example provided by Kent is dead wrong becase the
> >precision should have been carried by the 22th digit, what could even
> >not exist by adding two doubles !)
>
> That is not what he said. He said the opposite. Perhaps there is some
> problem in the translation.
Here is the original post:
============================
-----Message d'origine-----
> De : Kent Rollins [mailto:kentr@xxxxxxxxxxxxxx]
> Envoye : dimanche 22 juillet 2001 00:25
> A : OmegaList
> Objet : Re: Precision Errors
>
>For example, if you add 0.000111111111111 to 1,000,000,000 you
> might end up with something like 1,000,000,000.1.
>
> These are extreme examples but this is how precision is lost
> across repeated math operations.
================================
I' sorry to repeat again that this example is not well choosen to explain
why you lose precision after REPEATED math operation.Nothing to blame, the
result is perfectly normal, regardless the language.
There is nothing to expect from such operation, even performed once, and has
nothing to do with the original thread that was how to avoid loss of
precision using Float ( and at least lose less than what I had read).
>
>
> >My 9999999 limit in the average_WC test was beyond this limit to
> >avoid to have a part of the higher number carried by the exponent at
> >the detriment of the mantissa.
>
> This and your comment above indicate that you think that TradeStation
> uses integer arithmetic up to +-2^31 and floating point (24 bit
> mantissa and 8 bit exponent) for bigger numbers. Perhaps you are
> correct but I seriously doubt it. (Most other programming languages
> allow the programmer to specify this explicitly but EasyLanguage does
> not.) I understood that all numbers were handled as floats. It would
> be very time consuming to check all arithmetic operations at run time
> and do any required integer-to-float conversions. Does anybody else
> know for sure?
>
> If all numbers are floats, as I believe, your 9999999 limit is much
> smaller than the actual limit. My tests show that the limit would be
> at least:
>
> 1,234,567,948,140,544.
No, it cannot!
the above number has 16 digits,and the last 8 digits are pure garbage.
It cannot be coded in the 2^24 mantissa with that precision (that is
limited to 8 digits in a decimal base).
Again you are confused by what TS displays in the message log after the 8th
digit and that is anything you want excepted precision.
The theoretical limit should be 8388608 (2^24-1), but it may slightly
differ.
Numbers above are of course possible in EL, but they will be stored as
xxxxxxx 10^y ( if expressed in a decimal format), where xxx ..xxx represents
the digits known for sure.
If the message log ( print) was displaying the numbers in a scientific
manner, the problem should be more easier to understand.
Your number would display 1.2345678 10^15, what is for real.
1,234,567,948,140,544 is not for real when speaking of a float and of
numerical precision
1.2345678 10^15 is.
Again, you cannot expect more precision by converting a 23 bit number (base
2) into a base 10, so you do not have the right to display the extra Ts
garbage numbers.
And TS should not display them...
>
> >From your other examples, it appears that the 7 digits is the limit
> >of TS precision, what is correct with what I say
>
> And consistent with what Kent, Gary, and I have been saying... The
> errors in the digits beyond 7 digits are normal and exactly what we
> would expect from single-precision floats.
>
Yes. So if it is garbage after 7 th digit, it has nothing to do here, and at
most in any math operation beyond this 7th digit.
>
> >and I have nothing more to add...
>
> I am also tired of the subject but feel compelled to correct your
> incorrect information, particularly when you ridicule others based
> upon your incorrect understanding of the facts.
If you like....
I am also tired to see the sempiternal complaint about bugs that are not
bugs, misunderstanding of basic maths ( what I may understand), but what I
do not like is that it always ends by TRAD fault ( what I CANNOT always
understand).
Maybe they are not Snow white, but not so dark as most of you suppose.
And when I disagree, I'm a little bit sarcastic, you know...
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies proud and complex free representative in France
|