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