Decimal floating point library
Hi all, I think it's correct to say that many of us would like to see an IEEE conforming implementation of a decimal floating point library in boost. AFAIK C++ is the last of the important programming languages which has none in it's standard library. While it's for sure a major project to start from scratch and write a complete implementation (I don't know if there ever will be a group of people who are able *and* willing to do that...), there's maybe another option: IBM has recently put their C implementation (which is widely known as reference implementation) under GPL as part of GCC. It would be quite easy to write a C++ wrapper around this library and put it all together into boost, and I would volunteer to do that. So: - are we allowed to do that? - is this desirable? Thoughts? Stefan
Stefan Slapeta wrote: [...] Sorry, I forgot: http://www2.hursley.ibm.com/decimal/ Stefan
Stefan Slapeta wrote:
IBM has recently put their C implementation (which is widely known as reference implementation) under GPL as part of GCC. It would be quite easy to write a C++ wrapper around this library and put it all together into boost, and I would volunteer to do that.
The GPL is incompatible with Boost's license. -- Eric Niebler Boost Consulting www.boost-consulting.com
- are we allowed to do that? - is this desirable?
Sigh.. we really do need a good C++ binding for decimal arithmetic, and Boost would be a good place to develop one, however as Eric has already pointed out the GPL is not compatible with Boost's license: IBM currently charge a lot of money I believe for commercial users of their code. John.
John Maddock wrote:
Sigh.. we really do need a good C++ binding for decimal arithmetic, and Boost would be a good place to develop one, however as Eric has already pointed out the GPL is not compatible with Boost's license: IBM currently charge a lot of money I believe for commercial users of their code.
yes. However, if they give it away unter GPL, there may be the same option for boost, too. (BTW, I'm just curious: what are the major incompatibilities between the licences?) As we know, Mike Cowlishaw who is the author of this library is very commited to standardization both in IEEE and SC22. Is it worth asking? If yes, who should do that? Stefan
On 2/27/06, Stefan Slapeta <stefan@slapeta.com> wrote:
John Maddock wrote: However, if they give it away unter GPL, there may be the same option for boost, too. (BTW, I'm just curious: what are the major incompatibilities between the licences?)
Boost allows distribution in compiled form with no distribution of source code or attribution nessecary. Under the GPL, the FSF's belief is that code using GPLed code must also be released under the GPL, which most commercial vendors--that would be competing with IBM--would not do. Under the Boost Software License, commercial closed-source projects can use the code just about however they like, which gives IBM absolutely no advantage ( no name recognition or goodwill from the community ) and can help their competitors. ~ Scott
me22 wrote:
Boost allows distribution in compiled form with no distribution of source code or attribution nessecary. Under the GPL, the FSF's belief is that code using GPLed code must also be released under the GPL, which most commercial vendors--that would be competing with IBM--would not do. Under the Boost Software License, commercial closed-source projects can use the code just about however they like, which gives IBM absolutely no advantage ( no name recognition or goodwill from the community ) and can help their competitors.
ok, understood. sigh again.... stefan
Boost allows distribution in compiled form with no distribution of source code or attribution nessecary. Under the GPL, the FSF's belief is that code using GPLed code must also be released under the GPL, which most commercial vendors--that would be competing with IBM--would not do. Under the Boost Software License, commercial closed-source projects can use the code just about however they like, which gives IBM absolutely no advantage ( no name recognition or goodwill from the community ) and can help their competitors.
Right: it's not even under the LGPL, but the "full" version, which means it can only be used in applications also licenced under the GPL. John.
Work is already underway in the C++ committee on the following Work Item: "JTC1.22.24733 - ISO/IEC TR 24733 - Information Technology - Programming Languages C++ - Technical Report of Type 2 on Extensions for the programming language C++ to support decimal floating point arithmetic" The latest draft of this document is not yet on the WG21 committee website, but I imagine that it will be very soon. You can see an older draft there now: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1839.html
<klarer@ca.ibm.com> wrote in message news:du2c32$ejq$1@sea.gmane.org...
Work is already underway in the C++ committee on the following Work Item:
"JTC1.22.24733 - ISO/IEC TR 24733 - Information Technology - Programming Languages C++ - Technical Report of Type 2 on Extensions for the programming language C++ to support decimal floating point arithmetic"
The latest draft of this document is not yet on the WG21 committee website, but I imagine that it will be very soon. You can see an older draft there now: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1839.html
The current mailing just became available. The latest version of the decimal arithmetic proposal is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1965.html Stefan (or others), would you have any interest in implementing this proposal for Boost (under the Boost license)? 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. 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++. --Beman
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. 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) 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... Stefan
"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
Beman Dawes wrote: [...]
I assume you meant "the story *isn't* over here":-)
Anyway ... :-)
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.
They are for sure. A decimal with a zero scale is an integer.
(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.
yes, and "multa petentibus multa desunt" ;-)
We don't have (1) or (2) for binary arithmetic yet. How is decimal special in that regard?
Why would we need that for binary arithmetic?
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.
I'll see what I can do, but it's a large job. I'm off now for 4 weeks and I'll create something to start with afterwards. And we should also take the discussions during the boost decimal review into account. Stefan
participants (6)
-
Beman Dawes -
Eric Niebler -
John Maddock -
klarer＠ca.ibm.com -
me22 -
Stefan Slapeta