Status & Contents of TR2 W.R.T. C++ Specification

Question

Reference Link: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf

I am trying to gather information about TR2 and how it relates to the upcoming C++ Standard, if it does at all.

Here are my questions so far. If I've missed any important questions, please answer those as well. :)

Preliminaries:

1. The current C++ Standard is silent on the acutual binary representation of floating-point values. All it says is that floating point representation is "implementation defined." In practice, every implementation I'm aware of uses IEEE 754-2008. But this is not a requirement of the Standard.
2. TR2 identifies new types to be added to the language: decimal32, decimal64, and decimal128.

Questions/Points For Comment:

1. Are the new types above (decimal64 etc) going to be native to the language, or provided in a library?
2. Do the new types do anything to resolve the issue of floating-point imprecision? If so, how?
3. Does TR2 mandate a specific binary representation for these (or any) types?
4. Is TR2 going to be accepted as part of an upcoming C++ Standard? If so, when?
5. Is an implementation of these new types available in any currently-available library (eg, Boost)?

Kmeson

Native types added to the language? Aren't these going to be classes provided by the library (and in a tr2 namespace to boot)? – Playreader

@Ben: Edited question to incorporate your comment as an unknown (to me) – Kmeson

+1 for tagging c++0x, not c++1x. – Ibo

@downvoters: If you think something is wrong with this question, let me know. I'm happy to edit it if something is deficient. – Kmeson

Interestingly, there already are three other questions tagged tr2, but from what I saw at a glance, those were all mis-tagged. – Maddie

@Tomalak: Even though the new standard will likely become C++11? :) – Maddie

Answer 1

FYI, the linked document isn't TR2. "TR2" refers to a set of library extensions, in the same style as TR1, while the draft for "decimal floating point arithmetic extensions" is just that. There is no TR2 draft yet and it was originally planned to come out after 0x. So from here on, I'll assume that you aren't asking about TR2, but the linked document.

1. Library: However, the draft defines new classes under std::decimal which could easily wrap a native type provided by the platform/implementation. This TR does not define decimal literals.
2. Yes: "The most efficient way to avoid conversion error is to use decimal arithmetic. Recognizing this, the IEEE 754-2008 Standard for Floating-Point Arithmetic specifies decimal floating-point encodings and arithmetic. This technical report specifies extensions to the International Standard for the C++ programming language to permit the use of decimal arithmetic in a manner consistent with the IEEE 754-2008 standard."
3. Yes: The three decimal encoding formats defined in IEEE 754-2008 correspond to the three decimal floating types std::decimal::decimal32, 64, and 128. Refer to the decimalN links in the table here.
4. There's no sign of these proposals in the current C++0x draft. Maybe in the next standard, but not even the members of the committee could tell you when that will come out.
5. I didn't see any decimal libraries mentioning this specific draft when I did a quick web search, but there are a few out there if you just need a library.

Fullerton

Answer 2

I happened to be at the meeting where IBM initially proposed the decimal types to WG14 and WG21. Their initial proposal was to provide them as native types, which is pretty much the only solution in C. However, WG21 wasn't entirely convinced and pointed out that C++ already has std::complex<> as a mathematical type in the library, so why not std::decimal<>? Initial confusion about the performance overhead was quickly ended when it was pointer out that std::decimal could obviously wrap a _Decimal compiler extension.

After poiting out that this could be done in a library, the next question was then whether this should be in the Standard library. It's after all a specialized domain in which this is useful. The most commonly though-of domain, finance, doesn't actually need it (they really need decimal fixed-point, not decimal floating point). IBM didn't push their proposal a lot further, after this feedback.

These types do not resolve the issue of floating-point inaccuracy. 1/3 still isn't representable. However, 1/5 is.

Interspace

Isn't 1/3 a problem with the finite decimal/binary representation, rather than floating-point specifically? A fixed-point number would have the same limitation. – Fullerton

@Steve: That's what I was thinking too. You would have the same problem trying to write the value 1/3 down on paper in decimal form without the use of overbars. – Kmeson

I guess "the issue" of floating-point accuracy is the inability to be able to exactly represent any rational number that you could write down using only digits, decimals and negative signs. – Kmeson

Well, in decimal floating point you can represent 1/5, which you can't in binary floating point. And in ternary floating point, 1/3 is just 0.1 obviously. So, the real problem is with all those floating point formats is that they all have to choose one base, and fractions in other bases are problematic no matter what base you pick. The babylonians actually had a good point when they used base-60 minutes and seconds ;) – Interspace

Answer 3

decNumber++ is a reference implementation by IBM.

Patti