"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