Re: guile & r5rs

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

Radey Shouman <Radey_Shouman@splashtech.com> writes:

 > Tel <telford@eng.uts.edu.au> writes:
 > 
 > > > latter is (round (/ num (expt 2 nf))).  Very nice.  Now what do you do
 > > > to make it round towards even? :).
 > > 
 > > Please don't make the divide round towards even, this is a very
 > > strange function to work with when doing iterative calculations
 > > since it's behaviour changes for odd and even numbers.
 > 
 > The question as I understood it was whether the arguments to the
 > divide should be rounded towards even on the boundary case, when
 > bits to be rounded off are '1000000000000000000000000000 ... 0'

Yes, that's what I was talking about.

 > That is, we're double rounding and thus presumably already in a
 > state of sin.  The rounding of the actual result would depend on
 > the underlying floating point divide, and probably *would* round
 > towards even in the boundary case.

Yes, and, btw, R4RS dictates that round round towards even:

 - essential procedure: round X
     These procedures return integers.  `Floor' returns the largest
     integer not larger than X.  `Ceiling' returns the smallest integer
     not smaller than X.  `Truncate' returns the integer closest to X
     whose absolute value is not larger than the absolute value of X.
     `Round' returns the closest integer to X, rounding to even when X
     is halfway between two integers.

     *Rationale:*  `Round' rounds to even for consistency with the
     default rounding mode specified by the IEEE floating point
     standard.

 > I'm not sure I understand the concern about odd vs even numbers.  In
 > the cases we're discussing hundreds of bits of precision will be lost,
 > odd vs even of the original arguments is not even in the noise.

Hence the smilie face.

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