Path: utzoo!attcan!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: floating point multiplication BUG in C (cc compiler)
Message-ID: <4050@goanna.cs.rmit.oz.au>
Date: 23 Oct 90 02:15:42 GMT
References: <1348@banach.ACA.MCC.COM> <4032@goanna.cs.rmit.oz.au> <RICHARD.90Oct22112830@lambda.iesd.auc.dk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 29

In article <4032@goanna.cs.rmit.oz.au> I wrote:
> The problem here is that a number like 0.64 *CANNOT* *POSSIBLY* be
> represented exactly in (finite-precision) floating-point.  At all.
> In *any* programming language. [...]

In article <RICHARD.90Oct22112830@lambda.iesd.auc.dk>,
richard@iesd.auc.dk (Richard Flamsholt S0rensen) replied:
>   At least when using *binary* logic as your hardware  ;-)

I think he may have meant binary floating-point, and at that he
may have meant "radix-2 floating-point", or in fact "floating-
point with radix not a power of 10".

I had some mail by people who hadn't paid any attention to the
context.  The context was that the original poster was upset because
his program hadn't worked on six compiler/hardware combinations.
In that context, _only_ the floating-point systems actually available
to that poster are of relevance:  a radix-10 floating-point system
with 99 digits in the significand, whatever its merits, is of no
interest because not available to that poster.

I also note that 2 is distinctly better than other bases for floating-
point arithmetic.  I'm not just referring to the hidden bit (it's hard
to "hide" more than one bit...), I'm referring to the law
	X (<) Y --> X (<=) {X (+) Y}(/)2 (<=) Y
which bisection relies on.

-- 
Fear most of all to be in error.	-- Kierkegaard, quoting Socrates.