Re: fix for expt bug

[Andy Wingo <wingo@pobox.com>]

Hi,

On Mon 08 Nov 2010 22:08, ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@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/