[decimal] Proposed portable implementation ofstd::decimal
Hi all. A first draft of this library is available at https://sourceforge.net/projects/stddecimal/ Runs on MSVC10 and gcc 4.6.3. Wraps the Intel implementation only, Until we resolve the licencing issue, top-level README contains detailed instructions about where to get 3rd party code and what to do with it. I'm keen on feedback on a particular point (although all feedback is of course welcome!): The current project can parse and execute the test cases maintained by Mike Cowlishaw from http://speleotrove.com/decimal/ (referred to as the Test Cases). To be completely clear, I also have normal, interface testing test cases, I am *not* talking about those below. - Question: How useful do people feel the Test Cases to be? I originally expected 99% of these tests to pass, but it turns out that most of them require: - The operands to be parsed and stored at the precision they appear in the Test Case file - The operation to be performed at precision of the operands - The high precision result to be rounded to the precision required by the Test Cases. - The test inputs to be parsed with correct rounding in underflow situations (not required by IEEE afaik) The above requirements are based on my experience with the tests - it is possible I'm making a blunder somewhere. Since the Test Cases are really testing the 3rd party library, an argument could be made they are not essential, or even desirable. I'm inclined to think they would be very, very nice to have, as they would give users a lot of confidence - I suspect user uptake would be poor without this confidence. So... what do people think? Regards, Josh. (PS gmail seems to be confused about who 'boost' is, so apologies for the cross-posts!)
A first draft of this library is available at https://sourceforge.net/projects/stddecimal/ Runs on MSVC10 and gcc 4.6.3.
Wraps the Intel implementation only, In my opinion, this is a good start. But to really improve the
Until we resolve the licencing issue, top-level README contains detailed instructions about where to get 3rd party code and what to do with it. As far as I know, you simply won't get the third party code into boost. Perhaps I'm wrong here. But the best you can do is create a front end C++ implementation in as portable a way as possible and
OK, Josh. Sorry I have not weighed in on this interesting proposal until now. I have included some very detailed comments below. portability and usefulness of your proposal, you might want to consider writing your own portable decimal back end. provide a mechanism for linking with prebuilt versions of the 3rd-party library. This is, for example, what we have done with GNU GMP, MPFR and MPIR in association with the proposed Boost.Multiprecision library.
I'm keen on feedback on a particular point (although all feedback is of course welcome!):
So... what do people think? Regards, Josh.
Josh, I believe you have made a good start. But as mentioned above, a boost decimal implementation really would, in my opinion, mandate a fully portable boost-owned decimal back end. It looks like we are entering, well, a very *numeric* time at boost. Just take a look at the review schedule. We've got quaternions, multiprecision, complex numbers and there has been recent interest in creating a potential boost fixed-point implementation. It only makes sense to consider a decimal implementation. But we would need to figure out how this would best fit into the existing (and potentially future) numerical context of boost. I know, you can never please all the people all the time. But from a guy who has written numerous custom number back ends, here's what I would suggest: 1) Consider writing your own fully portable, boost-owned decimal. Provide the Intel compatibility as an optimized back-end for selected architecture. You would need a bit more software architecture to support multiple back ends. 2) I'm probably jumping the gun here, but you may want to take a look at the back-end requirements for a number type in the proposed Boost.Multiprecision. You might eventually want to target compatibility with this potential boost library. 3) You have some amounts of code in cpp source files. In my opinion, a decimal implementation should be header-only. The one exception is the use of library code mentioned earlier. One of the powers of boost is its portability. And this is strongly facilitated with its emphasis on header-only libraries. 4) Is there any connection between decimal and fixed-point? If so, do you want to contact Vicente Escriba who is concerned with fixed-point? 5) Do you need any elementary transcendental functions such as sin, cos, tan, exp, log, etc. Do you want to support any of these? Do your potential users need them? If so, I could potentially point you in the right direction for getting started on some potentially sensible algorithms in the digit ranges you are targeting. Again, to iterate lika a broken record... Why don't you make a first attempt at writing the code for the *guts* of the decimal types. I would be in a position to assist you with this, if you would like. However, I will be available at the earliest in fall for any significant contribution on a project with this level of complexity. Good luck on this interesting project. Best regards, Chris.
Hi Chris,
A first draft of this library is available at https://sourceforge.net/projects/stddecimal/ Runs on MSVC10 and gcc 4.6.3.
Wraps the Intel implementation only, In my opinion, this is a good start. But to really improve the portability and usefulness of your proposal, you might want to consider writing your own portable decimal back end.
As tempting as this sounds, I don't have the skill, and certainly don't have the time. If anyone finds this idea appealing, I'm more than happy to help out with testing.
As far as I know, you simply won't get the third party code into boost. Perhaps I'm wrong here. But the best you can do is create a front end C++ implementation in as portable a way as possible and provide a mechanism for linking with prebuilt versions of the 3rd-party library. This is, for example, what we have done with GNU GMP, MPFR and MPIR in association with the proposed Boost.Multiprecision library.
Sounds reasonable. Is the GPL license compatible with the boost license? The decNumber is available under GPL. We should also contact the library authors and see if they will grant permission to include the libraries under terms amenable to the boost license - both libraries were made available for gcc but I'm not sure if both are under the GPL. How would 'boost' go about this - I could contact the authors but I wouldn't like to pose as a boost representative without some sort of permission!
But we would need to figure out how this would best fit into the existing (and potentially future) numerical context of boost. [SNIP] here's what I would suggest:
1) Consider writing your own fully portable, boost-owned decimal. Provide the Intel compatibility as an optimized back-end for selected architecture. You would need a bit more software architecture to support multiple back ends.
As above regarding writing own backend. Regarding software architecture, the rudiments are in place (a half-implementation using decNumber is done but not committed).
2) I'm probably jumping the gun here, but you may want to take a look at the back-end requirements for a number type in the proposed Boost.Multiprecision. You might eventually want to target compatibility with this potential boost library.
I'll take a look, but the goal as I see it is complying with the std::decimal proposal - that is, to fill the gap until it becomes standard and all compilers support it. This doesn't preclude extended functionality being bolted on.
3) You have some amounts of code in cpp source files. In my opinion, a decimal implementation should be header-only. The one exception is the use of library code mentioned earlier. One of the powers of boost is its portability. And this is strongly facilitated with its emphasis on header-only libraries.
I'd have though the implementation of the actual numerics is complex enough to benefit from being compiled into a library - but I have little insight into the pros and cons of the two approaches. As an alternative, would making the back-end C compliant (or C-with-pass-by- reference) be enough to facilitate portability? Both 3rd party backends are C, and I see no reason for a boost owned version to be much different. The wrappers I've provided thus far could certainly be header only, but I'm working on the assumption that's pointless if you are insisting on a compiled back-end.
4) Is there any connection between decimal and fixed-point? If so, do you want to contact Vicente Escriba who is concerned with fixed-point?
I don't think there is a connection apart from optionally providing direct conversion between the two, however I'll take a closer look at the fixed point library.
5) Do you need any elementary transcendental functions such as sin, cos, tan, exp, log, etc. Do you want to support any of these? Do your potential users need them? If so, I could potentially point you in the right direction for getting started on some potentially sensible algorithms in the digit ranges you are targeting.
Yes, I was planning on using the versions of these functions supplied by the 3rd party code. Also, the standard doesn't specify the accuracy of most of these functions, so conversion to and from floating point is an option in the early stages.
Again, to iterate lika a broken record...
Why don't you make a first attempt at writing the code for the *guts* of the decimal types. I would be in a position to assist you with this, if you would like. However, I will be available at the earliest in fall for any significant contribution on a project with this level of complexity.
It'd be a great project, but I don't have the time. My primary goal is to implement this for my own purposes - given C libraries and a blueprint of the C++ interface a freely available this is a fairly trivial task. Even if this library doesn't make it into boost proper, I think it will still be valuable to have a proven wrapper + 3rd party combo that developers can use with some confidence as to it's reliability - even if they have to grab both parts separately. Since it's following a proposed standard, users can expect continuing support - at the very least that something similar will eventually be provided by compilers. At any rate, having the wrapper with support for multiple back-ends and all the tests in place will be a good starting point for anyone who should wish to implement their own version of a floating point decimal! Thanks again for such detailed feedback! Regards, Josh.
participants (2)
-
Christopher Kormanyos -
Josh Quigley