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)?

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.

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.