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
> 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
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk