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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-04-18 22:36:15

james.jones_at_[hidden] wrote:
>> 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.

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