Specific-Width Floating-Point Typedefs
There has recently been some discussion on improving portability of programs using floating-point. Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point. Our draft document (in both html and pdf) is at https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in... https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precisi... We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body. But would welcome comments from Boosters to help us improve this proposal. Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
The link 'The proposed typedefs and potential extensions' from the https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in... doesn't work. I get a 404 error.
From: pbristow@hetp.u-net.com To: boost@lists.boost.org Date: Thu, 28 Mar 2013 12:28:01 +0000 Subject: [boost] Specific-Width Floating-Point Typedefs
There has recently been some discussion on improving portability of programs using floating-point.
Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point.
Our draft document (in both html and pdf) is at
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in...
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precisi...
We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body.
But would welcome comments from Boosters to help us improve this proposal.
Thank you.
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2013-03-28 13:28, Paul A. Bristow wrote:
There has recently been some discussion on improving portability of programs using floating-point.
A common use case for fixed-length floats that you do not mention explicitly in your document is the exchange of floats over binary network protocols, such as the Google Protocol Buffer [1] or Message Pack [2]. Here the concern is not so much about the fidelity of calculations, but rather to have a common binary representation of floats. It may be worth adding this use case. [1] https://developers.google.com/protocol-buffers/docs/encoding [2] http://wiki.msgpack.org/display/MSGPACK/Format+specification PS: Many of the links in the html document are broken.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bjorn Reese Sent: Thursday, March 28, 2013 12:58 PM To: boost@lists.boost.org Subject: Re: [boost] Specific-Width Floating-Point Typedefs
On 2013-03-28 13:28, Paul A. Bristow wrote:
There has recently been some discussion on improving portability of programs using floating-point.
A common use case for fixed-length floats that you do not mention explicitly in your document is the exchange of floats over binary network protocols, such as the Google Protocol Buffer [1] or Message Pack [2]. Here the concern is not so much about the fidelity of calculations, but rather to have a common binary representation of floats. It may be worth adding this use case.
[1] https://developers.google.com/protocol-buffers/docs/encoding [2] http://wiki.msgpack.org/display/MSGPACK/Format+specification
Thanks - this is indeed another use case that we will reference.
PS: Many of the links in the html document are broken.
Thanks too for reporting this - missing files now added to SVN and committed. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Thu, Mar 28, 2013 at 13:58:21 +0100, Bjorn Reese wrote:
On 2013-03-28 13:28, Paul A. Bristow wrote:
There has recently been some discussion on improving portability of programs using floating-point.
A common use case for fixed-length floats that you do not mention explicitly in your document is the exchange of floats over binary network protocols
That adds requirement that they be IEEE 754 formats though. While I don't
know platform using any other format these days, I don't think C++ requires
that just as it does not require two's complement for signed integers.
So there would have to be one set of typedefs for just size/precision and
another for the IEEE 754 standard formats.
--
Jan 'Bulb' Hudec
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jan Hudec Sent: Wednesday, April 03, 2013 10:27 PM To: boost@lists.boost.org Subject: Re: [boost] Specific-Width Floating-Point Typedefs
On Thu, Mar 28, 2013 at 13:58:21 +0100, Bjorn Reese wrote:
On 2013-03-28 13:28, Paul A. Bristow wrote:
There has recently been some discussion on improving portability of programs using floating-point.
A common use case for fixed-length floats that you do not mention explicitly in your document is the exchange of floats over binary network protocols
That adds requirement that they be IEEE 754 formats though. While I don't know platform using any other format these days, I don't think C++ requires that just as it does not require two's complement for signed integers.
So there would have to be one set of typedefs for just size/precision and another for the IEEE 754 standard formats.
One could have both, but for simplicity, I think we only have IEEE 754 standard formats in mind (including the extended formats to get 128 bits - and up?). http://en.wikipedia.org/wiki/Extended_precision http://en.wikipedia.org/wiki/Quadruple_precision As you observe, hardly anyone is currently doing anything else, http://stackoverflow.com/questions/2234468/do-any-real-world-cpus-not-use-ie... so there is really no portability case. It doesn't seem worth making the names longer to distinguish the two cases. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 28/03/13 13:28, Paul A. Bristow wrote:
There has recently been some discussion on improving portability of programs using floating-point.
Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point.
Our draft document (in both html and pdf) is at
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in...
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precisi...
We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body.
But would welcome comments from Boosters to help us improve this proposal.
Seems simple enough. Personally I've grown used to assume float is float32_t and double is float64_t, but it could be useful to have proper typedefs for this.
But would welcome comments from Boosters to help us improve this proposal.
Personally I've grown used to assume float is float32_t and double is float64_t, but it could be useful to have proper typedefs for this.
Thank you for your comments, Mathias. For sure, I wish it were that simple. It sounds simple enough, but it's really a multifaceted issue. In my microcontroller and numerical travels, I have used * native float with 24 and 32 bits * native double with 32, 64, 80, and 128 bits * native long double with 64, 80, and 128 bits It's a nightmare! And just when you think you wrote some good code for double, it doesn't run somewhere because double is all of a sudden float. We are aiming at portability improvements here. Sincerely, Chris.
Our draft document (in both html and pdf) is at
Hey Paul, I would like to change the title of our own document to: "Floating-Point Typedefs with Specified Width" This phrase matches thw wording of C11, and is repeated time and time again as a form of jargon in our text. OK? Sorry I missed this one. Sincerely, Chris
Christopher Kormanyos
"Floating-Point Typedefs with Specified Width"
This phrase matches thw wording of C11, and is repeated time and time again as a form of jargon in our text.
My C11 draft doesn't mention these typedefs. Maybe it's out of date, or maybe I just failed to find it, but would you please point me to the section where this is discussed? Thanks, PM
"Floating-Point Typedefs with Specified Width"
This phrase matches the wording of C11, and is repeated time and time again as a form of jargon in our text.
My C11 draft doesn't mention these typedefs. Maybe it's out of date, or maybe I just failed to find it, but would you please point me to the section where this is discussed?
Petr,
My post may have been confusing. I mean that
C11 mentions:
"integer types having specified widths"
which motivated me to suggest:
"Floating-Point Typedefs Having Specified Widths"
At any rate, in ISO/IEC 9899:2011, Section 7.20.1,
there is the clause shown below.
Best regards, Chris.
--------------------------------------------------------------
7.20 Integer types
Christopher Kormanyos
"Floating-Point Typedefs with Specified Width" This phrase matches the wording of C11
My C11 draft doesn't mention these typedefs.
My post may have been confusing. I mean that
C11 mentions: "integer types having specified widths"
which motivated me to suggest: "Floating-Point Typedefs Having Specified Widths"
Ah, understood. Yes, such consistency definitely makes sense. Thanks, PM
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A. Bristow Sent: Thursday, March 28, 2013 12:28 PM To: boost@lists.boost.org Subject: [boost] Specific-Width Floating-Point Typedefs
There has recently been some discussion on improving portability of programs using floating-point.
Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point.
Our draft document (in both html and pdf) is at
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in...
https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precisi...
We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body.
But would welcome comments from Boosters to help us improve this proposal.
In case anyone following this thread is interested, I attach a cross posting of our replies to comments from Nick MacLaren from the British Standards WG21 subgroup. Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 09/04/13 11:32, Paul A. Bristow wrote:
In case anyone following this thread is interested, I attach a cross posting of our replies to comments from Nick MacLaren from the British Standards WG21 subgroup.
I haven't found a simple way to reply to that email, so sorry for the bad formatting.
1 templates mean that it isn't POD
That's not true. There is nothing in the definition of POD that is related to templates. What he probably meant to say is that a template class cannot be a fundamental type (while a fundamental type is a POD, a POD isn't necessarily a fundamental type). But then again, it being a template doesn't require a template class to be involved; it could be implemented with template aliases that could forward to a fundamental type if needed. It's a QoI issue.
how to specify constants with higher precision than long double
If the new extended literal mechanism doesn't allow to do this as a library, then it should probably be fixed.
3 Ours is a simple pragmatic solution using existing hardware and no new software. We don't expect 'reproducible execution', but experience with Boost.Math's extensive test suite suggests that it is jolly close. (It's the number of bits that make the significant differences). We're specifying types not strict semantics.
From my experience Boost.Math is lacking when it comes to denormals, nans or inf. Those are the tricky bits when different architectures are considered.
4 Almost all C++ uses the X86 FP
What is "the X86 FP"? Results on x86 are highly variable depending on the microarchitecture, compilation flags and mood of the optimizer. (arbitrary usage of x87, SSE, FMA3, FMA4 may all lead to different results).
7 float64_t will not use 80 bits, but float80_t will.
The C++ language allows the compiler to use higher precision for intermediate floating-point computations whenever it wants. The way the above is phrased, it could be misunderstood that computations with float64_t may never use a 80-bit precision floating-point unit, even though that may well likely happen. This gives a false sense of security to people who write some code that would only work with a IEEE754 64-bit floating-point unit.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Friday, May 03, 2013 12:06 PM To: boost@lists.boost.org Subject: Re: [boost] Specific-Width Floating-Point Typedefs
On 09/04/13 11:32, Paul A. Bristow wrote:
In case anyone following this thread is interested, I attach a cross posting of our replies to comments from Nick MacLaren from the British Standards WG21 subgroup.
I haven't found a simple way to reply to that email, so sorry for the bad formatting.
1 templates mean that it isn't POD
That's not true. There is nothing in the definition of POD that is related to templates. What he probably meant to say is that a template class cannot be a fundamental type (while a fundamental type is a POD, a POD isn't necessarily a fundamental type). But then again, it being a template doesn't require a template class to be involved; it could be implemented with template aliases that could forward to a fundamental type if needed. It's a QoI issue.
how to specify constants with higher precision than long double
If the new extended literal mechanism doesn't allow to do this as a library, then it should
fixed.
3 Ours is a simple pragmatic solution using existing hardware and no new software. We don't expect 'reproducible execution', but experience with Boost.Math's extensive test suite suggests that it is jolly close. (It's the number of bits that make the significant differences). We're specifying types not strict semantics.
From my experience Boost.Math is lacking when it comes to denormals, nans or inf. Those are the
probably be tricky
bits when different architectures are considered.
4 Almost all C++ uses the X86 FP
What is "the X86 FP"? Results on x86 are highly variable depending on the microarchitecture, compilation flags and mood of the optimizer. (arbitrary usage of x87, SSE, FMA3, FMA4 may all lead to different results).
7 float64_t will not use 80 bits, but float80_t will.
The C++ language allows the compiler to use higher precision for intermediate floating-point computations whenever it wants.
The way the above is phrased, it could be misunderstood that computations with float64_t may never use a 80-bit precision floating-point unit, even though that may well likely happen. This gives a false sense of security to people who write some code that would only work with a IEEE754 64-bit floating-point unit.
Agree with all your comments. The number of bits is by far the most important factor in precision. This is a simple pragmatic proposal that will make things better - but not perfect. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
El 03/05/2013 13:05, Mathias Gaunard escribió:
7 float64_t will not use 80 bits, but float80_t will.
The C++ language allows the compiler to use higher precision for intermediate floating-point computations whenever it wants.
Searching information to define specific-width types for my company, I've just read this thread and the proposal https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/in... First of all, thank you Paul, Christopher and John for your proposal, I think floating point typedefs are needed, and IMHO the paper is a big step in the right direction. I have some comments I'd like to share authors and boosters since I've seen that the paper has been updated after WG21/SG6 meeting so I guess numeric experts have reviewed the paper so many of my doubts might have been already discussed. Sorry if some comments are not accurate as I'm not an expert in floating point representations. * * * I don't think defining non-portable types like float80_t will help. As a programmer, I find stdint.h "rules" are quite easy to understand and they only define fixed-width types if they have a portable binary representation (except endianness). int32_t has no padding and it's 2's complement. If float32_t is defined I think it's ok to require it to be IEEE single precission with no padding, guaranteeing CHAR_BIT * sizeof(float32_t) is exactly 32. But if float80_t is defined the number of padding bits and their position shouldn't be implementation defined as it won't be consistent with integer types. We have float_least80_t for non-portable representations. <Off-topic>: Latest C and C++ standards are not consistent with stdint.h guidelines as they define char16_t and char32_t typedefs (and _Char16_t, _Char32_t native types in C++) with no width and padding guarantees. char_least16_t and char_least32_t (and "short char" & "long char" for native type names) would be more appropriate names that maintain type consistency. Following stdint.h rules, char16_t and char32_t types would be exactly 16 and 32 types with Unicode-16 and Unicode-32 encoding. It's difficult to teach and error prone that uint32_t has exactly 32 bits but char16_t can have more than 16 bits.</Off-topic> Since C/C++ floating point base/radix is implementation defined, float_least32_t does not offer much information about the base or the precision (the number of base-b digits in the significand). With int_least32_t I know INT_LEAST32_MIN is { -(2(N-1)-1) or lower }. I have no guarantee that I can store there INT32_MIN, but at least I know what can be portably stored. Assuming all current and future machines will be 2's complement (C & C++ only admit sign/magnitude, 1's complement, and 2's complement) I could decide int_least32_t can hold INT32_MIN. Since according to the proposal float_leastN_t types are optional, wouldn't be better to assume that float_[least|max]N_t types have binary base and at least the same precision as floatN_t (which are IEEE types with well known precision)? A DSP might only have binary64 floating point types, but a programmer can use float_least32_t to store a binary32 number with no rounding. The same can be applied to float_least80_t, a programmer can't know where the padding is but he/she knows that 2^-(2^70) can be safely stored there. Does this make sense? Best, Ion
participants (8)
-
Bjorn Reese -
Christopher Kormanyos -
Ion Gaztañaga -
Jan Hudec -
Mathias Gaunard -
Paul A. Bristow -
Petr Machata -
Ryan Boghean