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