# Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-03-07 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-
>> than-zero 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 all-positive 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 APV-efficient.

```--
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
```