Re: [boost] [Test] BOOST_CHECK_CLOSE Feature request

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2005-11-15 10:21:54

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Ian McCulloch
| Sent: 13 November 2005 22:11
| To: boost_at_[hidden]
| Subject: Re: [boost] [Test] BOOST_CHECK_CLOSE Feature request
| 
| John Maddock wrote:
| 
| >> Related to this, there is a very interesting article on 
| comparing IEEE
| >> floats at
| >> 
| http://www.cygnus-software.com/papers/comparingfloats/comparin
| gfloats.htm
| >>
| >> This makes use of the property that IEEE floating point formats are
| >> lexicographically ordered when reinterpreted as an 
| appropriate length
| >> signed integer.  It appears you can use this to define a closeness
| >> measure based on how many units in the last place the two numbers
| >> differ by (equivalently, if you enumerated all possible floats and
| >> counted how far
| >> away one number is from the other in the enumeration).  I only just
| >> came across it now so I havn't tried playing with it yet, but it
| >> looks like it would make a useful closeness measure.
| > 
| > I must admit I've been looking for a way to measure errors as ULP. 
| > However, I have my doubts about this: are integer types and 
| floating point
| > types
| > always of the same endianness? I suspect not, but can't be 
| 100% sure. 
| > There are also problems with long doubles to consider: 
| padding bits on
| > some implementations, and strange "a long double is 
| actually a pair of
| > doubles" on Darwin.
| 
| It is frustrating, that the article shows that it is quite 
| easy to do a
| ULP-based comparison given the right hardware (even doing 
| some bit-banging
| on eg, Darwin would be not so hard), but a portable version 
| to use as a
| fallback seems really hard.  Maybe it is possible using 
| frexp(), ldexp()
| etc.  The problem is if you don't assume IEEE arithmetic, 
| then there isn't
| much you can guarantee about floating point behaviour.  Not to mention
| handling FLT_RADIX != 2 ...  Scalbn() might be useful there, 
| but that is
| C99 only...

But TR1 pulls in C99, so we should be able to start relying on it?

| There is also the problem of platforms that are not quite IEEE.  For
| example, IIRC on Alpha by default doesn't generate subnormals.

This is correct, but I am not sure that this matters in making the
comparison?

Expectations of total portability seem misguided in any case IMO.
So can't we simply test for IEEE fp layout with
numeric_limits<>::is_iec599()
and give up if not?

As a specific example, I have recently been using NTL quad_float type
(simillar to Darwin  long double) to check that the Math functions can use a
UDT.  This worked fine with Boost Test and I think just adding a version for
this and other UDTs as the need arises is all we can hope for.

Paul

-- 
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
Phone and SMS text [phone], Mobile and SMS text [phone]
mailto: pbristow_at_[hidden]  www.hetp.u-net.com