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