| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Ian McCulloch | Sent: 13 November 2005 22:11 | To: boost@lists.boost.org | 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 +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com