[boost] Re: Thoughts on fixdec

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-07-16 15:01:34

Bill Seymour <bill-at-the-office_at_[hidden]> wrote in message
news:3F154B31.B449972C_at_pobox.com...
> Daryle Walker wrote:

>
>(Yes, I know that some numeric purists [and GCC] hate "long double,"
>but I want to maximize the capabilities.)
>
The problem with a 'long double' ctor, either with or without 'double' ctor,
is that long double is never the target of floating-point promotions, so
decimal construction would become ambiguous from some types.

> >
> > 1. We have two math-related namespaces already.  The boost::math
> > namespace leans to theoretical work and boost::numeric leans to
> > hard-core computation.
> >
>
> I don't know that there's anything particularly theoretical about
> decimal representations; and the library's target audience is not
> those users who do "hard-code computation," which I understand to
> mean numerical programming (in the sense of scientific and
> statical programming).
>
> It's not a major issue for me; and I'll do whatever the majority
> wants.
>
I'm inclined toward boost::numeric.

> >
> > You should probably pick one of those namespaces (numeric?) and
> > possibly rename the class to "fixed_decimal".
> >
>
> I'm reticent to require the user to type the extra "fixed_" in
> every declaration of such an object.
>
I prefer just 'decimal' because most decimal numbers I know of are
fixed-point.
So I think 'fixed' can be left implicit.

>
> >
> > 5. The conversion from "int" needs to check for overflow.
> > The conversion from "double" needs to check also for underflow.
> > The conversion from strings needs to check also for bad formats.
> >
>
> But that would require some users to pay for something they don't
> need.  Users who need that level of correctness can write their
> own checks; and others (probably most of the library's target
> audience) get better efficiency.
>
Couldn't this be provided as a postcondition, in terms of BOOST_ASSERT?

>
> >
> > 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.

>
> >
> > 9. What, no "operator <<" nor "operator >>"?  (The shift would
> > be a power of ten.)
> >
>
> Those operators don't exist for the floating-point types, and with
> good reason IMO.  Their use is best reserved for twiddling bits,
> not for scaling.  Even for binary integers, i << 1 is not generally
> the same thing as i * 2 except on 2's-complement boxes.
>
I agree.

> >
> > 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.

No class, specially a class modeling a number, should violate that.

You can use something of the form "x[keep_scale]=y;" for that special
semantics.

Fernando Cacciola