This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 are here. Eventually, the entire history will be moved there, including any new messages.
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