Re: Problem in Float Arithmetic


"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message news:b7ks64t16l75q6sv8a2650pv5j89l4k0aa@xxxxxxxxxx
On Fri, 4 Jul 2008 00:15:43 +0100, "David Webber"
<dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

My statements are most certainly not "false".

The statements of yours that I'm talking about are trivially false. The
example code I presented demonstrates this.

As Joe says in the following message

"So the simple explanation is best: "Floating point is not precise. Deal with it."

"Any exceptions to this rule are special cases and only result in confusion because the
user is misled by seeing one special case working to generalize that all cases will
necessarily work."

It might appear to be be a
subtle philosophical difference - whether you regard double x=1.0; as
representing the integer 1, or a number which is indistinguishable from 1
only if you look no further than16 sig figs.

Oh, nonsense. In the example I presented, in the context I spelled out, the
double I initialized with 1 faithfully represents the integer 1, and not
some approximation.

As I say that view stems from a particular philosophy in which some numbers are more equal than others. double(1) also equally represents 1+10^-20 and an infinite number of other real numbers.

If you really believe what you're saying, then you must
also believe....

I think it is a rather desperate argument when you start telling people what they "must believe".

Perhaps if you'd see the point of my statement that floating point numbers
are not exact, instead of arguing against it, I might realise that you knew
more about the subject than you are letting on. :-)

If you would read what I wrote literally, you wouldn't continue to
misrepresent what I said.

Then I have misunderstood.

I've given you no reason whatsoever to believe I
think floating point numbers are real numbers, ...

No - and I don't think they're the same thing as real numbers either, they are a "representation" of real numbers, and an inexact one.

3/7, e, pi, sqrt(265) are all very precise real numbers of which finite decimal approximations are just that - approximations.

( I actually have my own fraction class capable of representing all rationals which can be expressed as a ratio of integers which can be stored in 32 bits. I use it when I know that I am interested in rationals only, and its operations with real numbers are exact. )

yet there you go again
implying that's what I think. Not only am I not arguing that FP == real,

As i say, i know that fp isn't the only way of expressing a real number, and never suspected you didn't. (BTW FP is called "REAL" in FORTRAN)

the fact is, I've explained to people on many occasions that FP numbers are
not real numbers and don't behave like real numbers in most cases.

Well actually they behave exactly like finite floating point representations of real numbers in all caes.

Emphasising the infinitessimal subset of floating point operations where no
error propagates, is only going to lull people into a false sense of
security, instead of challenging them to think about error propagation
through their calculations.

Oh, nonsense. I did not challenge any general statement about the inexact
nature of floating point.
I described an important subset of values and
operations for which FP operations work as one would hope they do, and I
wouldn't have responded at all if you hadn't repeated a false categorical
statement. You misinterpret brief factual corrections as "emphasis" only
because this is such a hobbyhorse for you, which is also why you respond to
the corrections with lengthy, irrelevant treatises.

Well actually my "lengthy treatise" was very precisely relevant to the OP's problem, and adding integers cast to double precision isn't.

And my categorical statement is very generally true. The fact that you choose to interpret double(1) as 1.0 with an infinite number of trailing zeroes is an assumption which is only tenable for a tiny subset of operations on a tiny subset of floating point numbers. And one which will land people in trouble very quickly.

Still, I'm obviously not going to convince you, and that was never my objective. It was the OP I was concerned about, and Joe has summarised my concerns eloquently enough.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm



.

Relevant Pages

  • Re: Floating point rounding error
    ... Floating point rounding error's a cool scene! ... Is this rule of representing decimals in binary applicable only to ... This doesn't represent decimals. ... Dig the even newer still, yet more improved, sig! ...
    (comp.lang.c)
  • Re: Big numbers
    ... The exact value represented by that floating point literal in the ... closest that 'double' can get to representing that particular number ... and perform the usual unsigned overflow mechanisms, ... Alternatively the input mechanism will accept a string, ...
    (comp.lang.c)
  • Re: Float comparison
    ... Are Floating Point Constants "constant" from 1998. ... that a stored floating-point value can be interpreted as representing ... an exact value *or* a range of values. ...
    (comp.lang.c)
  • Re: Big numbers
    ... and I cannot convert it to a string anymore, ... The exact value represented by that floating point literal in the source code is converted first to a double, and only converted to 'unsigned long long' after wards. ... Apparently, on marc's machine, the closest that 'double' can get to representing that particular number is a number that is closer to 33748440199875752 than it is to 33748440199875750. ...
    (comp.lang.c)
  • Re: why system providing routies will provide different result in C++ and Fortran
    ... approximations - and I'm all for teaching it to all who will listen... ... bigger and more straightforward error would be if someone assumed that when angles==90, that the floating point value of r could ever be identical to pi/2.... ... it is possible to have an exact zero. ... point values large enough that the LSB has a place value close to or greater than one. ...
    (comp.lang.fortran)
Loading