Re: [boost] Specific-Width Floating-Point Typedefs

Subject: Re: [boost] Specific-Width Floating-Point Typedefs
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-04-09 05:32:06

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Paul A. Bristow
> Sent: Thursday, March 28, 2013 12:28 PM
> To: boost_at_[hidden]
> 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/index.html
> 
> https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precision.pdf
> 
> 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
> [phone]  07714330204
> pbristow_at_[hidden]


attached mail follows:

> -----Original Message-----
> From: cxxpanel_at_[hidden] [mailto:cxxpanel_at_[hidden]] On Behalf Of N.M. Maclaren
> Sent: Wednesday, April 03, 2013 9:24 AM
> To: cxxpanel_at_[hidden]
> Subject: [cxxpanel] N3626 - precision
> 
> Sorry, Paul, but I regard N3626 as precisely the wrong way to approach this problem.  Of the many
things
> that the UK (the only OTHER active
> country!) opposed in C99, <stdint.h> was a major one - it seriously harms portability, especially
over time.
> But IEEE 784 has other issues that make its approach undesirable, too.
> 
> Fortran does this far more simply and generally.  The mechanisms cannot be used directly, but
templates
> are an adequate substitute, and here is a draft of what could be done, in just a few lines:
> 
>     template<int precision, int range = 0, bool IEE754 = false, ...>
>     class floating;
> 
>     precision is the minimum number of significant decimal digits
>     (e.g. up to 15 matches IEEE 754 64-bit).
> 
>     range is the minimum symmetric normalised decimal exponent range
>     (e.g. up to 307 matches IEEE 754 64-bit).
> 
>     Other options specify other conditions.
> 
>     If there is no such type, the class fails to resolve.
> 
> Obviously, this can be done for integers, too - Fortran does, and it's far more what portable
programs
> want than <stdint.h>:
> 
>     template<int range, ...>
>     class integer;
> 
>     range is the minimum symmetric decimal range (e.g. up to 18 matches
>     64-bit).
> 
> That's really all there is to it.
> 
> Now, let's get back to floating-point.  IEEE 754 (1984) wasn't perfect, but was at least simple.
IEEE 754
> (2010) is a mess.  Not merely does it have decimal floating-point (in two variants), which has now
been
> dropped by one of its two sponsors, it has several variants, its section on binding to languages
isn't
> compatible with even C/C++'s execution model (and got laughed out of court by WG5), and there's
more.
> Anyone who wants to specify IEEE 754 needs to specify at least:
> 
>     1) Whether binary must be used or decimal may be.  You have this one already.
> 
>     2) Whether an interchange format must be used or an extended or extendable one may be used.
> 
>     3) Whether this requires underflow to produce denormalised numbers, or whether abrupt
underflow is
> allowed.
> 
> There are more optional and unspecified aspects, but those are the main ones.  Let's not get into
the utter
> lunacy that is 'reproducible execution', because that way madness lies.

1  templates mean that it isn't POD - and that has a cost.  One is how to specify constants with
higher precision than long double.   And speed of course.

2  We have a template solution partly done with Boost.Multiprecision, including decimal and binary,
highly flexible, lots of precision possible, so watch this space.  But hard to make it as fast as FP
hardware.

In the long term, C++ needs both the template solution as well as
the simplistic floating-point typedefs having specified widths.

Basically our proposal is saying, take the types you already have and typedef them in a portable
way. And do this in the only way C++ *knows* floating-point portability, i.e. via IEEE-754.
It's simplistic, but practical. Furthermore, it puts floating-point portability in C++ roughly on
par with integer portability newly achieved with C++11.

We addressed std::int32_t, etc. before looking into template-based big integers.

Nick is also right in the sense that there is an existing proposal for template-based decimal types
is template-based. A corresponding template-based solution for binary floating-point would be
consistent with this.

In fact, we all crave template-based floats, as evidenced by Boost.Multiprecision.

At the same time, there is interest in fixed-point.

A comprehensive treatment of numbers in C++ could involve template solutions for:
* integer types (of POD origin) having specified widths
* floating-point types (of POD origin) having specified widths
* big integers of template nature
* the cross-over at int128_t, int256_t.
* binary floating-point of template nature
* decimal floating-point of template nature
* binary fixed-point of template nature
* rational templates

(Here, we have intentionally not included arbitrary-base floating-point representations for the sake
of keeping the implementation feasible).

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.

4  Almost all C++ uses the X86 FP, so major gain is in making sure OS changes don't quietly make
code non-portable.  

5  If other platforms are not portable, they won't compile - eg VAX/VMS not in IEEE mode.  So at
least you'll know what to expect - or not.

6 Underflow to produce denormalised numbers is pretty much standard - and its effects small. 

7  float64_t will not use 80 bits, but float80_t will.

We are on a long numerical road here. And our proposal is simply one more step along the way. The
template-based floating-point proposal will take significantly more time to write.

Paul with contributions from John Maddock and Christopher Kormanyos.

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]
------------------------------------
To unsubscribe from this group, send an email to:
cxxpanel-unsubscribe_at_[hidden]
Yahoo! Groups Links
<*> To visit your group on the web, go to:
    http://uk.groups.yahoo.com/group/cxxpanel/
<*> Your email settings:
    Individual Email | Traditional
<*> To change settings online go to:
    http://uk.groups.yahoo.com/group/cxxpanel/join
    (Yahoo! ID required)
<*> To change settings via email:
    cxxpanel-digest_at_[hidden] 
    cxxpanel-fullfeatured_at_[hidden]
<*> To unsubscribe from this group, send an email to:
    cxxpanel-unsubscribe_at_[hidden]
<*> Your use of Yahoo! Groups is subject to:
    http://uk.docs.yahoo.com/info/terms.html