From: Jeff Garland <jeff@crystalclearsoftware.com>

james.jones@firstinvestors.com wrote:

...

So here's my question again: Is there any interest in a Boost library that implementated decimal arithmetic but didn't use N2198?

What I have working now would use expression templates to implement context:

context<decimal32> ctx; decimal32 x = ctx(9912), y = ctx("9e+4"); decimal32 z = ctx(x + y); z = ctx(x * y); z = ctx(x - (3 * z));

Expression templates are awesome...well, except for all the real world code I've seen that does calculations reads data in from a db or file and then crunches it. So ET just does nothing for these cases...

I don't understand this - why can't I read in data from a file? ifstream f("data.txt"); context<decimal32> ctx; decimal32 x, y, z; ctx(f >> x >> y); // not implemented yet, but certainly could be z = ctx(x + y);

I'll also say that I don't find the above syntax natural...I just think

decimal32 x(9912), y("9e+4"); decimal32 z = x + y;

would be more expected. I'm sure you have good reasons, but from my perspective a number type should behave as much like a built-in type as possible.

This I totally understand, and agree with, but I'm not sure what the perfect solution is. My idea is to provide a user-customizable context class for all operations, and a lot of design decisions derive from this. The binary operations essentially have become TRInary operations; it isn't +(x,y), but rather +(x,y,context). Context participates in the operation. So the question is, how do we implement this without forcing the user to do something really ugly like: z = add(x, y, context); My solution was to wrap the expression in an instance of context. I've also provided for a default context so that you actually can use the syntax you prefer, but you lose a little flexibility: z = x + y; // uses default context x = z * z; // still using default context z = ctx(x + y); // uses context instance ctx x = ctx2(z * z); // uses a new context instance ctx2 The default context is currently implemented using a singleton (I'm aware that there are some real-world usage concerns about singletons).

...

2. However, in the presence of exceptions I believe that my usage is simpler than what is required by N2198, which is going to result in hardware traps and/or signals, rather than nice C++ exceptions. With a context class you can throw exceptions or allow user-defined behavior.

Didn't know that...yuck...

Well, this does make some sense, especially considering the plan to move to a hardware implementation at some point. Also, N2198 explicitly states that they're going for some level of C compatibility; obviously exceptions wouldn't fit that mold.

...

3. N2198 restricts users to 3 decimal types, which presumably match the IEEE754r implementation of decimal types. These are great for memory usage, but not so hot for performance, at least when implemented in software - too much bit-twiddling. A straightforward implementation of decimals using arrays to store coefficients is much less space-efficient, but runs faster. (My very rudimentary testing indicates that the ratio is around 2.5:1 on my hardware, a Sun server.)

Well, I guess my goal would be to see Boost.tr2 get started (even though we don't really have boost.tr1 finished). So I'd like to see a decimal interface that supports N2198 in software and can drop to hardware where it becomes available. I don't see how the 3 type restriction stops you from an array implementation under the hood (note that it's been at least 6 months since I looked at it). I'd be fine with well justified extensions -- seems to me these would serve as feedback to N2198. There's still a window to modify it I think...

The problem with the type restriction is that there are some cases where you want speed and some where you really care about memory. If I just say "decimal32" I can't distinguish the two. As you say, though, in a hardware implementation the distinction goes away, because all the bit-twiddling necessary to work with IEEE754r decimals is done fast in hardware.

Sorry, that's a complicated position for a yes/no question ;-)

That's OK - thanks for your comments! - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837