[boost] [rational] Announcing new maintainer -- call for feature requests

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-24 13:50:51

Dear All,

Several months ago I became the official maintainer of Boost.Rational, and am
just now getting around to considering proposed modifications to the library.

I would like to know:

1. Do people use Boost.Rational, and if so, what is it used for, and with what
template parameters?
2. What changes or additions would people like to see?

Here are the changes that have been proposed:

A. [me and others] Make int_type (and possibly param_type) public. This will be
done.
B. [Andras Erdei] Make rational more usable with limited precision integral
types by providing automatic rounding when the result of a computation can not
be represented exactly, or by asserting or throwing an exception in such cases.
C. [Andras Erdei] Provide automatic selection of the underlying int_type which
would be fastest for representing rational arithmetic with a specified
precision.

----
Proposal B
Andras's original proposal, if I understood it correctly, was to use a form of
rounding which could be computed as the natural side-effect of the existing
algorithm to compute a rational arithmetic operation, in the case that the
actual result could not be represented exactly using the underlying int_type. At
the time, I questioned whether it would be acceptable to change the current
behavior of rational, since some current users may be relying on it. This is
partly why I am asking question 1) above.
A more general solution would be to add an optional template parameter
representing a rounding policy, which could
- implement no rounding, silently resulting garbage in some cases (this is the
current implementation)
- implement Andras's rounding method
- throw an exception if rounding would be required
- assert if rounding would be required, or
- (possibly) implement some other rounding algorithm
The reason I qualified the last option with "possibly" is that implementing
alternate rounding policies may require completely different algorithms for the
basic operations, meaning that the implementations of the basic operations would
have to be moved into the rounding policy, which I'm reluctant to do.
Andras, please let me know if I have misrepresented your ideas.
For background, see these threads:
http://lists.boost.org/MailArchives/boost/msg76375.php
http://lists.boost.org/MailArchives/boost/msg80121.php
----
Jonathan