[boost] Re: Fixed-Decimal's Scale

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-07-19 23:37:47

On Saturday, July 19, 2003, at 7:59 AM, Bill Seymour wrote:

> I've been thinking about the related issues of whether decimal should 
> be a template and whether the scale should be immutable.
>
> First, I'm adamant that the user should be able to write
>
>   dollars = foo;
>
> without magically losing pennies or gaining mils; and I don't think 
> the user should have to type something like
>
>   dollars.assign_without_changing_frac_digits(foo);
>
> as a workaround to get that behavior.
>
> Given that, then as Daryle has correctly pointed out, standard library 
> sequence collections of decimals, and mutating algorithms that work on 
> sequences of decimals, don't work right unless all objects in the 
> sequence have the same scale.  This issue of "working right" must be 
> addressed before we worry about efficiency or the size of the objects.
>
> 1.  The scale could be part of the type (decimal becomes a class
>     template).
>
> 2.  A warning could be put in the documentation that says that
>     storing decimals of different scales in the standard
>     collections yields undefined behavior.
>
> 3.  I could try to work some other kind of magic.
>
> The main difference I see between 1 and 2 is whether it's possible for 
> the user to make the mistake.  In neither can we have collections of 
> different scales; but I now think that ought to be allowed if there's 
> some way I can make it work.  (Note, for example, that with either of 
> the first two solutions, 1, 1.2 and 1.23 can't be sorted!)  So I'd 
> like to try 3, at least as a mind experiment, before deciding on 1 or 
> 2.
>
> Note that copy construction works correctly; it's just assignment that 
> has the perverse behavior.
>
> Let's say I specialize std::swap() to swap scale as well as value, and 
> then specialize other standard algorithms to use swap where they might 
> otherwise use assignment.  Have I done enough?

I warned against making the users having to write custom versions of 
all STL.  I didn't mean the solution to be for you to do all the 
customizing yourself!  That's a ridiculous amount of busy-work.  It 
also fails on (at least) two counts:

1.	It fails when the user want to make their own STL-like algorithm, 
especially if they don't know they have to re-work the algorithm for 
the decimal family.
2.	Doesn't help at all with the STL containers, which you don't have 
access to how their assignment/copying is done.

Combining scales isn't as hopeless as you make it sound.  When objects 
of different scales are combined, you round to the less-precise scale.  
Why don't you go up to the maximum scale instead.

        1.3  $  2.98

Instead of chopping the above to one fractional digit, go to the max.  
That would be 2 for addition and 3 for multiplication.  You'll add or 
multiply the significands exactly and return the fully-precise result.  
Of course, this assumes each number represents that exact value. (You 
treat them like exact rationals and not a smear of values like 
floating-point).  And this has to be for the non-assignment forms, 
since the scale can change.  Some rounding would have to occur for the 
combo-assignment forms.

Daryle