Re: inum/double = on 64-bits

[Greg Troxel]

  On a debian alpha, a comparison like

          (= #x111111111111111 (exact->inexact #x111111111111110))

  gives #t, where on a 32-bit system it's #f.

Is the language clear on what the right answer is?  Are you saying
that the behavior is suboptimal, or a violation of R5RS?

On my system, I get #t.  A perhaps related suboptimality is in
printing large inexact values.

On NetBSD/i386 2.0ish, guile 1.6.5:

guile> (= #x111111111111111 (exact->inexact #x111111111111110))
#t
guile> #x111111111111110
76861433640456464
guile> (exact->inexact #x111111111111110)
76861433640456500.0
guile> (inexact->exact (exact->inexact #x111111111111110))
76861433640456464


NetBSD/sparc64 (LP64) 2.0ish, guile 1.6.4:

guile> (= #x111111111111111 (exact->inexact #x111111111111110))
#t
guile> #x111111111111110
76861433640456464
guile> (exact->inexact #x111111111111110)
76861433640456500.0
guile> (inexact->exact (exact->inexact #x111111111111110))
76861433640456464

It seems odd to me (from a user viewpoint, but also from thinking
about the implementation) that inexact->exact can restore information
that had appeared missing.
I wonder if I am seeing the effects of the extra floating point bits
beyond IEEE754 on i386, but I see the same behavior on sparc64.



-- 
        Greg Troxel <address@hidden>