Re: inum/double = on 64-bits

[Kevin Ryde]

Greg Troxel <address@hidden> writes:
>
> Is the language clear on what the right answer is?

r5rs cautions against relying on = for inexacts due to inaccuracies,
but I read that as inaccuracies from a calculation.

I'm looking at an inexact which is an integer, compared to an exact
which is an integer of a different value, and getting #t.

Such a comparison would give #f if you converted the inexact to an
exact first, I think it should be #f when you do it both ways.

In 1.8 comparisons (= bignum flonum) use the precise value of both, I
want to extend that to 64-bit inums for uniformity.  I think the same
would be good for 1.6, though that would need the bignum+flonum case
attacked too.

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

The printing of inexacts is fairly dodgy, I believe.  Convert to an
exact to print.

> On NetBSD/i386 2.0ish, guile 1.6.5:
>
> guile> (= #x111111111111111 (exact->inexact #x111111111111110))
> #t

I say it should be #f, which is what you get in 1.8.  But on i386 this
is the bignum+flonum case, I'm only looking at the inum+flonum at this
moment.

> NetBSD/sparc64 (LP64) 2.0ish, guile 1.6.4:
>
> guile> (= #x111111111111111 (exact->inexact #x111111111111110))
> #t

Yep, this is the one I say should be #f.  Those two values are not the
same.

> 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.

Those extra bits will affect intermediates in the C code, but the
actual SCM flonum is a double.