Bill Seymour <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost