Boost logo

Boost :

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

Fernando Cacciola

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