chicken-janitors
[Top][All Lists]
Advanced

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]