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] |
Jim Blandy <jimb@red-bean.com> writes: > > > So, how difficult is it to move all r5rs features to the main > > > stream of guile development? Does anybody work on this? > > > > Same thing for the full numeric tower and exactness. When will > > Guile follow the numeric standard ? Many people could also do maths > > with Guile... > > I don't have any plans to implement the full numeric tower at the > moment. This is explicitly permitted by R5RS. Guile does support > exact and inexact numbers. So, as far as I know, Guile does follow > the numeric standard; if you feel this is not so, please report it as > a bug. Actually, I don't think it does, and I did report it as a bug (on Oct 29th). I don't have a copy, but it's in the guile archive (I sent it to guile & bug-guile): To: guile@cygnus.com, bug-guile@gnu.org Subject: bignum bugs From: "Harvey J. Stein" <hjstein@bfr.co.il> Date: Thu, 29 Oct 1998 17:02:46 +0200 Message-Id: <199810291502.RAA27423@blinky.bfr.co.il> Sender: owner-guile@cygnus.com 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 -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il