[boost] [decimal] non-N2198 implementations

From: james.jones_at_[hidden]
Date: 2007-04-18 15:18:37

> From: Jeff Garland <jeff_at_[hidden]>
> > Fixed Decimal
> > 
> > Introduction: Fixed Decimal types provide an alternative to floating 
> > point types that are superior in their calculation properties. Robert 
> > Klarer of IBM has proposed adding these types to C++ [in n2198 (pdf)] 
> > and prior papers. This work is now on track to be included in C++0x. 
> > Robert has an implementation of these types with a restrained license. 
> > This project involves implementing the n2198 interfaces in a Boost library.
> 
> I have done a lot of work on something very similar to this that I was hoping to
> propose  airly soon (next few weeks). The interface isn't quite N2198, but I'm not
> crazy about N2198 anyway (it isn't threadsafe, for example, AFAICT). I've been
> using the IEEE754r spec. Is it worthwhile at all to continue to work on a BOOST
> library for fixed decimal arithmetic without making it N2198 compliant?

I brought this up a couple of weeks ago but the discussion got sidetracked by my thread safety question. I'm reasonably satisfied that N2198 can be written in a threadsafe way using <cfenv> now (if the fenv implementation is threadsafe, that is), but I'm still not totally happy with the extremely restrictive N2198 interface.

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

The expressions (e.g. "x*y") are evaluated within a context<decimal32> instance, which does exception trapping, etc. This gives the library user a lot of control - it also would easily allow a user to derive from context to implement their own behaviors.

There is also a facility for using a default singleton context as well for code that needs to be written in the form:

z = x * y;

There are several usage differences between my proposal and N2198:

1. N2198 is simpler to understand because it doesn't rely on expression templates. No question here.

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.

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

-
James Jones             Administrative Data Mgmt.
Webmaster               375 Raritan Center Pkwy, Suite A
Data Architect          Edison, NJ 08837