[boost] Re: Thoughts on fixdec

From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2003-07-17 07:21:48

Fernando Cacciola wrote:
>
> I'm inclined toward boost::numeric.
>

Two votes for boost::numeric.

>
> I prefer just 'decimal' because most decimal numbers I know of
> are fixed-point.  So I think 'fixed' can be left implicit.
>

Two votes (including mine) for "decimal;" two votes (including
Michel Andre's from a while back) for "fixed_decimal."

>
> Couldn't [overflow/underflow checks] be provided as a postcondition,
> in terms of BOOST_ASSERT?
>

I'll consider that.

Fernando:
>
> Me:
> >
> > Daryle:
> > >
> > > 6. There should only be conversions from strings, and _no_
> > > mixed operations with strings.
> > >
> >
> > In the absence of decimal literals, I think it's easier for the
> > user to be able to use strings as pseudo-literals in all contexts;
> > and I don't see how the mixed operations do any harm.
> >
>
> The problem is that quite unfortunately, string literals are just
> pointers to constant char, but such pointers are also used to access
> raw memory, so, char const* is the target to implicit conversions
> from a lot more than string literals. This would lead to unexpected
> implicit conversions.
>

But I think that C++ inherits that part of the "spirit of C" that
says, "Trust the programmer."  It's not that all programmers are
trustworthy, nor even that some programmers are always trustworthy.
It's that many programmers become increasingly trustworthy as they
gain more experience; and we want to reward that behavior. 8-)

Fernando:
>
> Me:
> >
> > Daryle:
> > > 
> > > 13. You have strange (regular) assignment semantics.  You try to
> > > change the receiver's logical value to the source's logical value,
> > > but retain the receiver's original scale (internally shifting the
> > > new significand and doing any rounding if needed).  ... you will
> > > get strange effects if you try to change containers of "decimal"
> > > through assignment.
> >
> > I thought it would be less surprising if a decimal object's scale
> > were immutable.  This matches prior art (the BCD type on IBM
> > mainframes, for example) in which the scale is part of the type.
> >
> > You're right about container<decimal>; but remember that this class
> > isn't intended for number-crunching; so I don't really care about
> > assigning matrices, etc.
> >
>
> But this isn't about assigning matrices and number-crunching, it's
> about C++ assignment semantics.   The postcondition of equivalence
> for assignment is a strongly fundamental feature of the C++ object
> model, and everything and everyone, not just containers, relies on
> that.
> 

Hmm...

I came up with two use cases:  figuring the final payment of a loan
and converting currency.  In both cases, I had to write the code
very carefully to /create/ the error I was worried about; and even
after doing so, neither case was particularly compelling.  You
might have convinced me.

Also, when considering the case of converting currencies, I saw
a problem with multiplication not being commutative:

  decimal dollars(2, 314.75);
  decimal exchange_rate(6, "0.890004");
  decimal euros(2);
 #if ONE_WAY_TO_DO_IT
  euros [round_up]= exchange_rate * dollars;
 #else
  euros = dollars [round_up]* exchange_rate;
 #endif

Programmers would have to be very careful with such code in any event;
so maybe my argument isn't a good one.

I still have an /emotional/ attachment to it, though.
I'll work on that. 8-)

Question:  should I go back to template<int Scale> class decimal?

Advantages:  The assignment semantics issue goes away because
             the scale is part of the type.

             It's more like prior art.

Disadvantages:  The scale must be a constant expression.

                There are member template issues with some compilers.

                It won't work at all with MSVC v5 which can't deduce
                non-type template arguments.  (OK, I could bite
                the bullet and maintain a non-Boost version
                for my own use at work; but I wouldn't be happy
                about it.)

--Bill Seymour