james.jones@firstinvestors.com wrote:
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
From: Jeff Garland <jeff@crystalclearsoftware.com> 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.
Well, now is the time to speak up...before it's locked in the standard.
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'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.
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.
Rightly so...see above.
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...
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... Sorry, that's a complicated position for a yes/no question ;-) Jeff