[boost] Re: [date_time] time_duration division

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.
>> 
>> Huh?
>> 
>>      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
at all...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com