"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:du6s9q$8ge$1@sea.gmane.org...
Beman Dawes wrote:
Stefan (or others), would you have any interest in implementing this proposal for Boost (under the Boost license)?
of course :-)
Although it would be a big job, the critical interface design and documentation work are essentially done in that you can just reference Robert's paper.
I don't fully agree. Robert's paper (which is again based on the WG14 library extension) specifies the interface for three IEEE conformant decimal types. The main intention of IEEE is to specify three decimal floating point types in order to be able to provide hardware support for these particular types later! Undoubtedly, this is welcome, but the story is over here.
I assume you meant "the story *isn't* over here":-) It has been quite a while, but IIRC the three proposed types are also supposed to be useful for decimal integers. To emphasize that, "floating-point" was removed from the name of the proposal. Perhaps Robert can clarify.
The requirements of mathematics, especialy for large integer computation, are another side and go far beyond this scope! What we need is:
(1) an arbitrary length integer type (2) an arbitrary length decimal floating point type, which is a combination of (1) with an integer-like scale so that decimal_value = large_integer_value / 10 ^ scale (3) three specializations of (2) to provide the IEEE and TR2 conforming interface (32, 64, 128 digits)
"The best is the enemy of the good," as Voltaire said. We don't have (1) or (2) for binary arithmetic yet. How is decimal special in that regard?
IMO (1) and (2) should have a template parameter that specifies the number of digits. Furthermore, it *could* be possible that (3) are plain typedefs.
It would a useful library for Boost users, and any issues you ran into would illuminate areas of Robert's proposal that needs more work. The resulting improvements would be of long term benefit for C++.
The usefulness is beyond any doubt. I would enjoy working on a decimal library, but I can't do that on my own. It's simply too much for one...
It might be possible to break the job down into: (A) A core decimal arithmetic engine (presumably tailorable to different lengths, and replicable by hardware if chip companies do start providing hardware engines.) (B) Public interfaces to the core engine. (C) A test suite for the core engine, concentrating on arithmetic correctness. (D) A test suite for the public interfaces, concentrating on interface correctness. If you make some progress on (A), perhaps others might volunteer to tackle the other parts. --Beman