[boost] Re: comparing computed f.p.values ( including powers) atcompiletime

From: Andy Little (andy_at_[hidden])
Date: 2003-11-11 16:09:32

Hi Paul,

"Paul A. Bristow" <boost_at_[hidden]> wrote in message
news:AHEJIHEOOOBMJPAGPLIPCEBPEKAA.boost_at_hetp.u-net.com...
> You will find some potentially useful background on _run-time_ floating
point
> comparisons (a minefield?) in the test library documentation:
>
> boost_1_30_2\libs\test\doc\floating_point_comparison.htm

Yep...I've got it ...thanks for pointing it out. I shall have a good read !

One thing that it does point out is that floating point comparisons arent
too useful with '=='.
I suppose that technically though if you cant say what '==' means you cant
say what '<' , '>',  etc means.

What might be useful is some sort of  " is it in range" operation, ie for
successive approximations,
I did think of constructing an operator to represent "in range" , with the
comma operator:

bool somefunc()
{
        PQ x;
        const PQ y;

        while (!giveUp()){
             calc(x);
             if (  x == (y , 1e-6) ){        //  ie is x in rangeof , y *
1.00...1 , y  * 0.99...9
                    return true;    //success
              }
         }
    return false ; // fail
}

but it may be easier just to call it in_range()  I suppose  ... :-)

BTW I have had a couple of thoughts on the comparison issue.
The algorithm I am currently using, involves doing a compare by transforming
each operand to the unit of the other.
If they appear to cross in the process then I call it  a yes. ( OR rather
than AND )  :-)
 Its probably not too scientific but it aims to be symmetrical!

As you may gather at the moment I am just trying for "something that works".

>
> implemmented in
>
> boost_1_30_2\boost\test\floating_point_comparison.hpp
>
> Some references from previous work:
>
> [1] Knuth D.E. The art of computer programming (vol II).
> [2] David Goldberg What Every Computer Scientist Should Know About
> Floating-Point Arithmetic
> [3] Kulisch U. Rounding near zero.
> [4] Philippe Langlois From Rounding Error Estimation to Automatic
Correction
> with Automatic Differentiation
> [5] Lots of information on William Kahan home page.
> [4] Alberto Squassabia Comparing Floats: How To Determine if Floating
Quantities
> Are Close Enough Once a Tolerance Has Been Reached C++ Report March 2000.
> [5] Pete Becker The Journeyman's Shop: Trap Handlers, Sticky Bits, and
> Floating-Point Comparisons C/C++ Users Journal December 2000.
>
> HTH
>
> Paul

Hmm... Right I think what I shall do is get this thing behaving about right
 and then I may have to come back and ask if I can pick your brains to sort
this stuff out .... ? :-)
... perhaps I should put Knuth on the Xmas list ... at last    :-)
>
> PS As you have discovered, C++ doesn't give much help with compile time FP
:-(

Yep.
The logs gets me out of a bit of a hole... So far the scheme is working, and
Its a lot better than nothing !
(and My log scheme is very basic. It could be refined a lot from here.)
To do it seriously I will obviously have to go through testing every
combination of units
, for a reasonable range of powers, and point up the combinations that dont
work.
However where the two give the wrong result one can be sure that the two
calced numbers are "about the same".

thanks for the refs

Andy Little
---------------------------
Thought I'd take the opportunity to correct my original example

> |     float const        x_v1;
    long const       x_p1;            // was float,should have been long ,
                                            //   long must be at least 4
bytes accd to std
> |     float const       z_v1;
> |
> |     float const       x_v2;
    long const       x_p2,            //again...
> |     float const       z_v2;

... I'm not doing fractional powers of a physical_quantity... not this time
anyway. Its too complicated :-)

[see previous on thread for the rest of the example]