Re: guile & r5rs

[hjstein@bfr.co.il (Harvey J. Stein)]

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