[Boost-commit] svn:boost r83563 - sandbox/precision/libs/precision/doc

Subject: [Boost-commit] svn:boost r83563 - sandbox/precision/libs/precision/doc
From: e_float_at_[hidden]
Date: 2013-03-25 15:33:28

Author: christopher_kormanyos
Date: 2013-03-25 15:33:27 EDT (Mon, 25 Mar 2013)
New Revision: 83563
URL: http://svn.boost.org/trac/boost/changeset/83563

Log:
Corrected some of my own typos and comments.
Text files modified: 
   sandbox/precision/libs/precision/doc/precision.qbk |    25 ++++++++++++++++++++-----               
   1 files changed, 20 insertions(+), 5 deletions(-)

Modified: sandbox/precision/libs/precision/doc/precision.qbk
==============================================================================
--- sandbox/precision/libs/precision/doc/precision.qbk	(original)
+++ sandbox/precision/libs/precision/doc/precision.qbk	2013-03-25 15:33:27 EDT (Mon, 25 Mar 2013)
@@ -176,6 +176,13 @@
 respectively. These are defined in __IEEE_floating_point, and there are more detailed descrptions
 of each type at __IEEE_Half, __IEEE_Single, __IEEE_Double, __IEEE_Quad, and __IEEE_Extended.
 
+Here, we specifically mean equivalence of the following.
+
+  float16_t  == binary16;
+  float32_t  == binary32;
+  float64_t  == binary64;
+  float128_t == binary128;
+
 One could envision two ways to name the proposed
 optional floating-point `typedef`s having specified width:
 
@@ -222,7 +229,7 @@
 Consider an implementation for a supercomputer. This platform might have
 `float`, `double`, and `long double` corresponding to IEEE754
 `binary32`, `binary64`, and `binary128`, respectively. In addition, this
-platform might have a user-defined type with octuple-precision.
+platform might have an implementation-specific type with octuple-precision.
 The implementation for this supercomputer could introduce
 its optional floating-point `typedef`s having specified width
 into the `std` namespace as shown below.
@@ -242,7 +249,8 @@
 does not have sufficient resources to support the eight-byte, 64-bit
 `binary64` type in a feasible fashion.
 An implementation for this platform can, however, support
-half-precision `float16_t` and single-precision `float32_t`.
+half-precision `float16_t` using an implementation-specific type
+and single-precision `float32_t`.
 This implementation could introduce
 its optional floating-point `typedef`s having specified width
 into the `std` namespace as shown below.
@@ -426,9 +434,16 @@
 This is considered an implementation detail.
 
 [note Support for `<limits>`, even where optional, can be quite
-useful. This allows programs query the floating-point limits
-and use, among other things, `std::numeric_limits<>::is_iec559`
-to determine if a floating-point type conforms with __IEEE_floating_point.]
+useful. This allows programs to query the floating-point limits
+at compile-time and use, among other things, `std::numeric_limits<>::is_iec559`
+to verify conformance with __IEEE_floating_point.]
+
+[note Each of the optional floating-point `typedef`s having specified width
+can only have `true` for the value of `std::numeric_limits<>::is_iec559`
+if its underlying type (be it `float`, `double`, `long double` or
+an implementation-dependent type) conforms with its corresponding
+cpecification of `binary16`, `binary32`, `binary64`, or `binary128`
+in __IEEE_floating_point.]
 
 [endsect] [/section:limitsinterop Interoperation with <limits>]