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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk