From: David Abrahams (dave_at_[hidden])
Date: 2003-09-04 19:34:03
"Jeff Garland" <jeff_at_[hidden]> writes:
> On Wed, 03 Sep 2003 15:10:13 -0400, David Abrahams wrote
>> "Jeff Garland" <jeff_at_[hidden]> writes:
>> >>Jeff G wrote:
>> >> I'm thinking it would have to be defined like this
>> >> Duration / Duration --> Integer
>> >>I think Duration / Duration --> double would be more appropriate.
>> > I have intentionally avoided floating point types in the library
>> > because there is no reason to suffer the loss of correctness
>> > associated with these types.
>> 3/2 == 1
>> is correct?
> Yes. Of course to make this useful you will need % as well.
>> You get a much bigger round-off error from ints than from floats.
> Yes, but you know what you are getting up front. With floats you don't know
> until runtime what the round-off will be. Anyway, I have yet to here a
> compelling use case in this domain for using non-integer arithmetic.
The arguments for using doubles or long doubles are:
1. The floating result is "less lossy" than the integer result in
almost all cases, which means you can get back to the integer
result you want from the floating result.
2. Of course, you can always do integer arithmetic with
t1.ticks() / t2.ticks()
If you make t1 / t2 the same as t1.ticks() / t2.ticks(), then to
get the floating result you need:
(double)t1.ticks() / t2.ticks()
which is, in all, more verbose.
3. You already have values with a great "dynamic range"; you have to
use a 64-bit integer type which may not always be built in, and
typical ticks * x / y computations may overflow.
I think if you'd be inclined to do integer math I might ask you to
leave it out. Hmm, maybe boost::rational can help here? Not lossy
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk