Hi, On Mon 08 Nov 2010 22:08, l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <m...@netris.org> writes: > >> No, (integer? 3.0) returns #t, as it should, according to R5RS. >> R5RS's description of "integer?" gives this precise example, and >> guile's implementation agrees. > > Damn, I had never realized that, shame on me. Bill Schottstaedt has a nice rant on https://ccrma.stanford.edu/software/snd/snd/s7.html. I think all of his examples are taken from Guile... I can't find the right tone for this section; this is the 400-th revision; I wish I were a better writer! I think the exact/inexact distinction in Scheme is confused and useless, and leads to verbose and buggy code. In some Schemes, "rational" means "could possibly be expressed equally well as a ratio (floats are approximations)". In s7 it's: "is actually expressed as a ratio (or an integer of course)"; otherwise "rational?" is the same as "real?": (not-s7-scheme)> (rational? (sqrt 2)) #t As I understand it, "inexact" originally meant "floating point", and "exact" meant integer or ratio of integers. But words have a life of their own. 0.0 somehow became an "inexact" integer (although it can be represented exactly in floating point). +inf.0 must be an integer — its fractional part is explicitly zero! But +nan.0... And then there's: (not-s7-scheme)> (integer? 9007199254740993.1) #t When does this matter? I often need to index into a vector, but the index is a float (a "real" in Scheme-speak: its fractional part can be non-zero). In one scheme: (not-s7-scheme)> (vector-ref #(0) (floor 0.1)) ERROR: Wrong type (expecting exact integer): 0.0 ; [why? "it's probably a programmer mistake"!] Not to worry, I'll use inexact->exact: (not-s7-scheme)> (inexact->exact 0.1) ; [why? "floats are ratios"!] 3602879701896397/36028797018963968 So I end up using the verbose (floor (inexact->exact ...)) everywhere, and even then I have no guarantee that I'll get a legal vector index. When I started work on s7, I thought perhaps "exact" could mean "is represented exactly in the computer". We'd have integers and ratios exact; reals and complex exact if they are exactly represented in the current floating point implementation. 0.0 and 0.5 might be exact if the printout isn't misleading, and 0.1 is inexact. "integer?" and friends would refer instead to the programmer's point of view. That is, if the programmer uses 1 or if the thing prints as 1, it is the integer 1, whereas 1.0 means floating point (not integer!). And to keep exactness in view, we'd have to monitor which operations introduce inexactness — a kind of interval arithmetic. But then what would inexact->exact do? If we discard the exact/inexact distinction, we can maintain backwards compatibility via: (define exact? rational?) (define (inexact? x) (not (rational? x))) (define inexact->exact rationalize) ; or floor (define (exact->inexact x) (* x 1.0)) There is also Mike Sperber's paper a few years ago about Scheme's numeric tower being borked. Anyway, just to say that you're in good company :) Andy -- http://wingolog.org/