This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

bignum bugs



I seem to be getting overflows I shouldn't get when working with
bignums.

Consider:

guile> (define a 2706660098140645489185923553970566016893099856360336323402524418695428905878508075836626775246052131230477353094376980271701893510989004673972199336498786760105507295770706655889359381824318115244951819800829175510325405549778256791513205371984083396827897605501338582435065123577807680901404556091719054173009876284055841904995815079252887561888975757510847638427607806239796367139527811680401979800)
guile> (define b 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
guile> (/ a b)
+#.#
guile> (sqrt a)
+#.#
guile> (sqrt b)
+#.#

R4RS says:

     Implementations are encouraged, but not required, to support exact
   integers and exact rationals of practically unlimited size and
   precision, and to implement the above procedures and the `/'
   procedure in such a way that they always return exact results when
   given exact arguments.  If one of these procedures is unable to
   deliver an exact result when given exact arguments, then it may
   either report a violation of an implementation restriction or it
   may silently coerce its result to an inexact number.  Such a
   coercion may cause an error later.

so I guess this isn't completely allowed behavior for /.  It's not
coercing the result to a double & it's not reporting an implementation
restriction violation.

It also says:

     In particular, implementations that use flonum representations must
   follow these rules: A flonum result must be represented with at
   least as much precision as is used to express any of the inexact
   arguments to that operation.  It is desirable (but not required)
   for potentially inexact operations such as `sqrt', when applied to
   exact arguments, to produce exact answers whenever possible (for
   example the square root of an exact 4 ought to be an exact 2).  If,
   however, an exact number is operated upon so as to produce an
   inexact result (as by `sqrt'), and if the result is represented as
   a flonum, then the most precise flonum format available must be
   used; but if the result is represented in some other way then the
   representation must have at least as much precision as the most
   precise flonum format available.

so this is definitely *not* allowed for sqrt.

Checking the code for /, I see that guile converts bignums to
doubles before dividing when the denominator doesn't divide the
numerator evenly.  I don't understand the use of SCM_PROC1(...,
scm_tc7_cxr,...), but I guess it automatically convert its argument to
a double & then runs the specified system fcn.

I'd say that since guile lacks rationals, / should be treated as sqrt
is said to be treated in R4RS, which would be to return the closest
double to the corresponding rational.  I'd think that this would be
the intension of the R4RS authors.

FWIW, it looks like STk has the same failing, except that it gets the
last sqrt right (it's a perfect square).  I don't have a copy of
Gambit handy, but from what I recall of its numerical code, I think it
gets it completely right.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il