
Boost : 
From: Daryle Walker (darylew_at_[hidden])
Date: 20010307 18:08:23
on 3/7/01 7:22 AM, Bill Seymour at bsey_at_[hidden] wrote:
> Daryle Walker wrote:
[SNIP comments of existing "more_math.zip" and Bill being inspired by a
rational class (besides boost::rational).]
>> enum rounding_mode
>> {
>> nearest, // down if < 1/2, up if >= 1/2
>> nearest_even, // down if < 1/2, up if > 1/2, to even if == 1/2
>> // following should be obvious from names
>> towards_zero,
>> towards_pos_infinity,
>> towards_neg_infinity,
>> leaving_zero
>> };
>>
>
> This is a little different from what I wrote...my round function
> always rounds to the nearest integer except in the special case
> where the remainder is exactly half of the divisor, so there is
> no "nearest" integer.
The previous statement sounds like you have no policy, and have the rounding
routine return a "n + 1/2" value, which breaks assumptions of an "integer
rounding" routine. (It returns 'X' rounded to an integer, except when it
doesn't!) If your rounding routines always return an integer, even in a
"n/1" rational form, then you need some sort of policy for handling 1/2
cases.
The "nearest" policy is the one I got taught in school (in the early 1980s).
That may not be the best name, though. I think previous generations were
taught the "nearest_even" rule.
>>> The second template argument indicates whether a signed divisor
>>> is known to be > 0, for example, in a rational number class that
>>> eagerly keeps its denominator positive. It has no effect iff
>>> T is an unsigned type.
>>
>> I don't get what you're trying to say here. Wouldn't the greater
>> thanzero property be dependent on what you put in the "divisor"
>> argument, and not as a template parameter.
>>
>
> Normally, the user would just let the second template argument
> default to false. In the example of the rational number class
> that I gave, the denominator is _known_ to be greater than zero
> at compile time (because the rational number class is written
> that way), so the code for floor, ceil, gcd, etc. can be more
> efficient.
I think the boost::rational class makes the same guarantee about keeping its
denominators positive. I'm not sure that slight efficiency for routines
using allpositive values is worth making a separate templates for them.
Some of the routines may not need separate versions anyway, e.g. I think the
GCD routine is automatically APVefficient.
 Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk