[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-janitors] #579: Numbers egg does not compute the same resul
From: |
Chicken Trac |
Subject: |
Re: [Chicken-janitors] #579: Numbers egg does not compute the same result as other schemes |
Date: |
Tue, 31 May 2011 22:06:31 -0000 |
#579: Numbers egg does not compute the same result as other schemes
-----------------------------+----------------------------------------------
Reporter: ckeen | Owner: sjamaan
Type: defect | Status: assigned
Priority: critical | Milestone: 4.8.0
Component: core libraries | Version: 4.7.x
Resolution: | Keywords: numbers egg
-----------------------------+----------------------------------------------
Comment(by sjamaan):
I think the real problem is that 64-bit floating point numbers only have
52 bits at their disposal; if the top-most bits of a 64 bit number _and_
the lowest bit of that number are used, pow() does '''not''' seem to set
errno:
{{{
gosh> (expt 999 6)
994014980014994001
gosh> (* 999 999 999 999 999 999)
994014980014994001
gosh> (* 999.0 999.0 999.0 999.0 999.0 999.0)
9.94014980014994e17
gosh> (inexact->exact (* 999.0 999.0 999.0 999.0 999.0 999.0))
994014980014994048
}}}
As you can see in the last call, precision is lost. This can be
reproduced in Chicken, and even simplified to:
{{{
#;1> (inexact->exact (exact->inexact 994014980014994001))
994014980014994048
}}}
There is no way to get around this I'm afraid; on 64-bits systems integers
can represent larger numbers than doubles when they have their lowest and
highest bits set :(
What's really annoying is that as far as I could find, nothing indicates
this truncation even happened! The comparison between m1 and r doesn't
help, since the truncation already happened before converting it to a
C_word, so it compares as being equal.
I ripped out the special case for fixpoint args so it always takes the
"slow" route in [23864] and the calculation now gives the correct result.
If you agree with this and don't know a better solution either, please
close the ticket and I'll tag a new release of "numbers". I'm unsure what
should happen in core; I suppose it can just return the wrong result since
there's nothing sane we can do.
God this sucks
--
Ticket URL: <https://bugs.call-cc.org/ticket/579#comment:11>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.
- Re: [Chicken-janitors] #579: Numbers egg does not compute the same result as other schemes, (continued)
- Re: [Chicken-janitors] #579: Numbers egg does not compute the same result as other schemes, Chicken Trac, 2011/05/27
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow() (was: Numbers egg does not compute the same result as other schemes), Chicken Trac, 2011/05/29
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/29
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/30
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/30
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/31
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/31
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/31
- Re: [Chicken-janitors] #579: expt does not check errno after calling pow(), Chicken Trac, 2011/05/31
- Re: [Chicken-janitors] #579: Numbers egg does not compute the same result as other schemes (was: expt does not check errno after calling pow()), Chicken Trac, 2011/05/31
- Re: [Chicken-janitors] #579: Numbers egg does not compute the same result as other schemes,
Chicken Trac <=