should double have better precision or greater range?

[Henry Spencer]

In article <8809061831.AA29128 at ucbvax.Berkeley.EDU> U23405 at UICVM (Michael J. Steiner) writes:
>I may go as far as to say that there should be two kinds of doubles, one
>with better precision and another with greater range...

X3J11 talked a bit about different kinds of floating-point, but I believe
that there was insufficient experience for anyone to be confident of doing
the right thing.  Note that these two kinds of doubles would be identical
on most real machines, since the hardware only offers one kind.

>Also, I recently heard of a "long double". Since double is defined as
>"long float", this would mean "long long float", which is confusing.

"Long double" was the one thing X3J11 did do, to accomodate the large and
growing number of machines that have an extra-large floating-point format.
IEEE floating point requires an "extended" format, for example.  (NB, there
are a number of machines that use IEEE data formats without implementing
the full IEEE standard.)  Another example is that 64-bit supercomputers
and that ilk will sometimes provide 128-bit floating point.  This seemed
an important thing to accommodate, and not too hard to handle.

"long float" as a synonym for "double" is actually gone, since nobody ever
used it.

>As far as I know, C doesn't allow this. (It would be nice, though, to make
>a data type as long as you want by saying "long long long long ... <type>")
>Anyone hear about this?

A nice idea in the abstract.  Algol 68 did this, although I think it had a
rule that the implementation could limit the number of underlying sizes
and simply start ignoring "longs" at some point.  There are people who have
implemented "long long int" in C.

>One last thing: Would an expression be evaluated more quickly if the RHS
>had variables of type short or type int? ...

With occasional exceptions, "int" is the type one uses if one is more
concerned about speed than about space or number range.  (A notable
exception is 68000/010 implementations that make "int" 32 bits to reduce
problems with poorly-written software; "short" may be faster there.)
"Short" can be noticeably slower than "int".
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry at zoo.toronto.edu