Re: Testing math functions

Richard Lynch wrote:

On Thu, August 23, 2007 10:28 am, Zoe Slattery wrote:

Hi - I've writing a few tests for the math extension and have a question about floating point precision. Here's a small example: --TEST-- Test return type and value for expected input sin() --INI-- precision = 14 --FILE-- <?php $threesixty = pi() * 2.0; echo "sin 360 = "; var_dump(sin($threesixty)); ?> --EXPECT-- sin 360 = float(-2.4492127076448E-16) Is it right to test for an exact number in this way? I was slightly suprised that I got the same number from Windows and Linux (maybe I shouldn't be). If not, I could write the test above to check that sin 360 is zero plus/minus some small number - but how small?

Seems to me that if 'precision' setting is supposed to affect the output of your calculations, then you should, in theory, be able to rely on 14 decimal places, no?... Actually that isn't what "precision=14" does. Precision=14 will just print out the first 14 digits of the answer ignoring leading zeros.

So when I change the ini setting to precision=3, the result I get for sin(360) is -2.45E-16, this doesn't help if the processor rounding error is > 1.0 E-16 say.

I realize that's an over-simplistic answer, perhaps, and I thought the precision only applied to BC_MATH and/or GMP calculations. I'm sorry - I don't know enough about BC_MATH or GMP to comment.

I'd be surprised if it was ALWAYS right for every OS, and I strongly suspect it's going to fail on 64-bit hardware big-time. As Piere says - and I just verified by using a few different processors - the answer is processor dependent.

I guess the first question I have is "What precisely are you testing?" The 'precision' setting? Nope :-)

Or just that sin(2 * M_PI) is kinda sorta close to 0? Yes - the most simple test of sin() or cos() functions is that they should give the expected result for known values.

If you just want "close to 0" then double the answer you are getting now, and call that "close enough" :-) Well - maybe. After trying a few different processors a reasonable thing to do seems to be to check that the answer of a floating point calculation is within "plus or minus 1.0E-10" of the expected result. This feels a bit arbitrary - but there doesn't seems to be a better solution (except maybe a lot of research into allowable rounding errors from each sort of processor technology and I don't think this particular case warrants that)

If you think 'precision' is supposed to affect it and guarantee 14 decimal places of precision, then 1.0E-14 to 1.0E14 should be your range, no? See above