[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inum/double = on 64-bits
From: |
Kevin Ryde |
Subject: |
Re: inum/double = on 64-bits |
Date: |
Fri, 07 Jan 2005 10:15:12 +1100 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) |
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.