[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flonum precision

This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.



Aubrey Jaffer asked several questions, which are easier to answer
in a different order than the order in which he asked them.

> And specifically which representations are "flonums"?
>
> The only definition R5RS gives for flonums is "Machine representations
> such as fixed point and floating point are referred to by names such
> as fixnum and flonum."

In the R5RS, "flonum" is nothing more than an informal name
for floating point representations.  This is spelled out in
greater detail in the relevant appendix of IEEE Std-1178.
(I think it's Appendix D.  BTW, that appendix, written by
Chris Hanson circa 1990, is IMO the single most important
commentary ever written on the subject of Scheme's arithmetic.)

> The second half is a strong statement; why are flonums specifically
> called out in the first half?

Flonums are the most important representations for inexact
numbers, and have finite precision, so the subject of precision
needs to be addressed.  Implementors who use other representations
with finite precision were expected to take their cue from the
discussion of flonums.

> Would floating-point numbers with latent explicit precision be
> flonums?

I don't know what "latent explicit precision" means, and I
probably wouldn't be able to answer the question even if I
knew.  We're talking about inexact arithmetic here, which is
very loosely specified (and deliberately so), so an overly
close reading is not justified IMO.

The language in that section sounds normative, because it
is derived from prose written by Gerry Sussman, who cares
a great deal about floating point computation, but that
normative-sounding prose has more attitude than substance.
Sussman's attitude was that the obvious implementation of
Scheme's inexact arithmetic uses flonums, as described in
the IEEE appendix, and that implementors who use other
representations should make sure they're at least as good
as flonums.

IMO, that approach to specification was fine when Scheme was
an experimental and research language, but users (and even
some implementors) are now asking for more guidance in the
form of a specification with enough teeth in it to provide
real portability.

Will