Re: [boost] [decimal] non-N2198 implementations

From: james.jones_at_[hidden]
Date: 2007-04-19 09:54:34

From: Jeff Garland <jeff_at_[hidden]>
>james.jones_at_[hidden] 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