Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at