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

From: Andy Little (andy_at_[hidden])
Date: 2005-04-09 08:11:39

"Andras Erdei" wrote
> On Mar 28, 2005 1:29 PM, Andy Little  wrote:

>> In many uses of rational the values are unlikely to overflow. Some uses are
>> in dividing a circle into degrees, minutes, or seconds, power of dimension in
>> a runtime physical-quantity, Storing imperial lengths eg 1 1/8 " (inch).
>
> the range of the values has nothing to do with the kind of "overflow" we are
> talking about; the same way as int or float "overflows" even for small values
> like 1 divided by 3, rational<> will overflow -- if you recall, there was an
> example at the very beginning of this discussion where adding 1.xxx to 2.xxx
> resulted in a negative number with boost::rational<>

The use of decimal point representation is not an ideal means to represent a
rational number. Use of a bigger int would solve the overflow
issue.

> my guess is that the only application where it does not happen is where you in
> fact only multiply rational<>s with integers (there was a poster who did
> this), but you do not need rational<> for that.

I disagree. . boost::rational  provides services such as conversion and i/o
which otherwise one has to manually code. It makes the intent clearer and is one
less thing to worry about.( you may also require division).  You may see this as
a trivial use.. but  I would certainly prefer to use it in this context, because
it models the problem well.

-- maybe your dividing a circle
> is such an application, but using imperial lengths (even adding two small
> ones) is not

The imperial lengths example is one where the gcd  for different units != 1.
This is a special case as Peter Dimov pointed out above in this thread.
My use of a rational number would be to store the units only (because of the
overflow issues) and use a double for the value.  To find the scaling value
between units involves only a division. As in the above case one could use an
integer, with "a tiny bit more work".

>> I would guess that these are the major uses of rational and all have values
>> in quite a small range.
>
> it is very hard to make guesses about the major uses of rational (all we know
> for sure is our own interest in this)

The applications I have cited may be relatively trivial but it is useful for
these.

[discusion on potential uses of a rational]

The heart of the issue seems to be  accuracy of analogue numbers. This is
obviously a big and important ( and neverending ) topic but I cant help feeling
it is a bit bigger than boost::rational. How about a boost::irrational or some
other name?

> it is not necessary to limit rational<> to use the same type for representing
> the numerator and denominator, so there is no single value_type/int_type to
> publish
>
> it is not necessary to limit rational<> to represent the numerator and
> denominator in separate members (i've posted a much more efficient
> implementation of the current boost::rational<> which requires both the
> numerator and denominator to be stored in the same data member to be
> efficient), so the published value_type/int_type may not convey any useful
> information for the users of rational<>, as you cannot define how is it
> related to rational<>

One would require it to interact with other types (presumably inbuilt types) at
least for purposes of initialisation and conversion.  You need to know what
types to use as initialisers.

>> As far as errors due to overflow, the problem is not actually in the
>> domain of rational  but of the value_type as has been stated before.
>
> stated, but not convincingly explained :O)

This is simply the finite_int, versus bigint issue. Use a bigint to avoid
overflow. Use an int for speed and small footprint, where you have a small range
in numerator, denominators values.

>> rational shouldnt need to know anything about the behaviour of its
>> value_types operations.
>
> but that requirement results in rational<>s that are both inefficient and
> useless (cannot round)

Is a rational number implementation that has been rounded, a rational
number?...  Yes, but not the one you expected. How do you know if it has been
rounded? Will the rounding be the same on different implementations. Keep
rational for use on 'rational numbers'  where absolute predicability,
repeatability and accuracy is required.

OTOH You have requirements for a type that has some of the theoretical
properties of rational but also with some of the properties of a float
(approximate representation of numbers which may or may not be rational
numbers). That is not rational but is interesting. Perhaps it would be
interesting to talk about how this type might be implemented and what its
properties and requirements might be.

regards
Andy Little