[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: andy@chestnut.com (Andy Latto)*Subject*: ROUNDing*From*: barmar@Think.COM (Barry Margolin)*Date*: Fri, 28 Jun 1991 11:55:00 -0400*Cc*: JGA@alderaan.scrc.symbolics.com, slug@ai.sri.com*In-reply-to*: <9106281530.AA18559@pecan.chestnut.com>

Date: Fri, 28 Jun 1991 11:30 EDT From: andy@chestnut.com (Andy Latto) > Date: Thu, 27 Jun 1991 18:50-0400 > From: barmar@Think.COM (Barry Margolin) > However, I happened to pick up a copy of Knuth later in the afternoon, > and found the section where he talks about rounding (Seminumerical > Algorithms, section 4.2.2). I couldn't find many details, but at one > point he said that the "right" way to round a number that is exactly > half-way between two units depends on the radix -- if it's even you > round towards the even number, if it's odd you round towards the odd > number. Then he pointed out that all the commonly-used bases are even, > so it's simplest to remember that rounding should be towards the even > number. I don't believe this, even if it's in Knuth. Rounding is an issue to do with numbers, not with numerals. If I ask you whether (round 1/2) is 0 or 1, how can the answer depend on what base I am using? What if I am using Roman Numerals? Or just tally marks, instead of radix notation? The context of Knuth's discussion was in rounding floating point numbers after a computation. I think the point was that extra digits are used internally during the computation (e.g. multiplying floats with 24-bit fractions results in a 48-bit fraction in the temporary), and then the result has to be rounded to the precision of the regular representation. barmar

**References**:**ROUNDing***From:*andy@chestnut.com (Andy Latto)

- Prev by Date:
**Re: :set-edges for window on a color screen** - Next by Date:
**[not about] Ellipsis mode for zmacs?** - Previous by thread:
**ROUNDing** - Next by thread:
**ROUNDing** - Index(es):