RE: [boost] Fixed-Point Decimal Type

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-05-09 16:19:24

----- Original Message -----
From: Ed Brey <brey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 09, 2001 6:04 PM
Subject: Re: [boost] Fixed-Point Decimal Type

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > > Yes, and you must be able to do binary operations with all numeric
> > > types without having to do explicit type conversions; using a
> > > float/double operand should give a float/double result,
> >
> > I don't think that mixed operations with floating point values should
> give a
> > floating point result.
> > If the class has absent/explicit constructors from fp types, this will
> > prevent many usual expressions;
> > and if it has regular constructors from fp-types it will produce too
> many
> > temporaries and conversions.
>
> Consider the sales tax use case:
>
> double rate1 = 1./3.;
> double rate2 = .051;
>
> fixed<2> subtotal(1, 23);
> fixed<2> tax1 = subtotal * rate1;
> fixed<2> tax2 = subtotal * rate2;
> fixed<2> total = subtotal + tax1 + tax 2;
>
> Observations:
>
> - The precision of the rate has no correlation to the precision of the
> currency, and moreover it is perfectly reasonable for a rate to use all
> the precision that the processor can handle, as in the 1/3 case.  This
> leads to the temptation to perform the multiplication in floating point
> and then round back to fixed, but then an evenly divisible rate like .5
> of .1 might not come out right.  Converting rate1 to a fixed seems to be
> the way to go, so long as it is a fixed<18> (or whatever the maximum
> size is).
>
> - To avoid the currencies-not-adding embarrassment, the calculation
> should return a fixed-point number, properly rounded off, even if this
> causes the total to not be equal to fixed<2>(1.23 * (1 + rate1 +
> rate2)).  (Another approach is to figure out the final total by adding
> the rates first, and then work backwards, fudging the taxes to make it
> all add up.  I don't know whether this is common practice in the
> business world, but in any case it seems like it would have to be hand
> crafted beyond what the "fixed" class would provide.)
>
> - Given guarantees like those implied above, hopefully it will not be
> necessary to require explicitly conversion when multiplying/dividing
> fixed and floating types.
>
>
I'm afraid I wasn't clear enough.
I complained about returning fp types, not about allowing mixed operations
without conversion.
In your examples:

 fixed<2> tax1 = subtotal * rate1;
 fixed<2> tax2 = subtotal * rate2;

the return value is inmedietly converted to a fixed.

That is: I suggested make all arithmetic operations return a fixed type, not
fp types

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com