Re: What's Your Interest in Integer Division Traits?

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