> Please do not separately post the same question to different newsgroups.
>> Please do not separately post the same question to different newsgroups.
>
[quoted text clipped - 5 lines]
>
>Well, it's not a bug, but a "feature".
No it's not a feature either. It's just reality interfering. :)
As with everything, it's important to know how things work so you can
explain the times when they don't. :)
<danielgud...@gmail.com> wrote...
...
>>As respondants in both threads have pointed out, this is a well
>>known property of finite precision arithmetic exacerbated by
>>binary representation of numbes. It is not a bug and is not
>>unique to Excel.
>
>Well, it's not a bug, but a "feature".
Feature in the sense that it's an UNAVOIDABLE aspect of the HARDWARE
to which ALL finite precision software applications that uses that
hardware are subject.
>Where in the hell is this "feature" explicited at help system ?
>Not so easy to find...
Anyone with any experience in numeric programming is aware of it.
>And of course, for a common user, a number is a number, and
>nothing more. . . .
Numbers as a mathematical concept are NEITHER FULLY NOR EXACTLY
supported on computers. The 'numbers' computers provide are
equivalence classes on a bounded subset of real numbers. Arithmetic on
these equivalence classes mostly duplicates mathematical arithmetic on
real numbers (within computer bounds) except near those equivalence
classes' boundary points. Then all bets are off.
If you don't like this, try to find other software that more nearly
meets your expectations. And good luck finding it!
>If it's typed at 2 decimal precision, it could be good that sum
>and multiplycation of it could be also at those 2 single decimal
>precision. No use of thinking about IEEE, 15 limit precision,
>binary internal representation, and so on... Unless the user ask
>for it.
...
You could always use the Precision As Displayed option, but it causes
other problems. But Excel provides ONLY two options in this regard:
IEEE double precision reals (basically Excel's 15 decimal digit
precision reals) and fixed point (Precision As Displayed). Choose the
one you want.
danieldc - 12 Apr 2007 14:13 GMT
> Anyone with any experience in numeric programming is aware of it.
Yes, I tried it in Delphi using double variables and the values
(115.00 , 113.20 , 1.80) and also got the same result (-2.88658E-15).
Of course, if I was to make a program, and not a excel worksheet, I
would use Currency or Longint types (this last divided or multiplied
by 100), or if going to use real/float types, all the time ensure the
correct round() or trunc() functions.
But this post I included not to talk about programming language or
advanced computation.
I'was with a problem using Excel: some numbers, 2 digit precision,
after sum and subtraction, results different from zero, where the only
value expected was zero.
And now, searching this forum, I found other posts about this same
affair.
> You could always use the Precision As Displayed option, but it causes
> other problems. But Excel provides ONLY two options in this regard:
> IEEE double precision reals (basically Excel's 15 decimal digit
> precision reals) and fixed point (Precision As Displayed). Choose the
> one you want.
I tried it but didn't get the results. As the final user could change
that option, it was better to lost some milliseconds at more trunc()
functions.
Thanks,
Daniel