# Testing math functions - Thread: https://externals.io/message/31868 - Original archive: https://news-web.php.net/php.internals/31868 - Started by Zoe Slattery on 2007-08-23T15:28:09+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31868 — Zoe Slattery — 2007-08-23T15:28:09+00:00 URL: https://externals.io/message/31868#31868 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-- --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? Zoe Slattery IBM --- ## #31909 — Richard Lynch — 2007-08-26T03:34:31+00:00 URL: https://externals.io/message/31868#31909 · In reply to: #31868 > 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-- > > $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?... I realize that's an over-simplistic answer, perhaps, and I thought the precision only applied to BC_MATH and/or GMP calculations. 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. I guess the first question I have is "What precisely are you testing?" The 'precision' setting? Or just that sin(2 * M_PI) is kinda sorta close to 0? If you just want "close to 0" then double the answer you are getting now, and call that "close enough" :-) 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? -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #31915 — Pierre — 2007-08-26T08:41:22+00:00 URL: https://externals.io/message/31868#31915 · In reply to: #31868 > 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-- > > $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? It really depends on the architecture. Using a precision of 10 should put you on the safe side, at least for the common architecture (intel, amd and ppc). --Pierre --- ## #31963 — Zoe Slattery — 2007-08-29T15:17:28+00:00 URL: https://externals.io/message/31868#31963 · In reply to: #31909 Richard Lynch wrote: > > > > […] > > 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 --- ## #31965 — Zoe Slattery — 2007-08-29T15:20:47+00:00 URL: https://externals.io/message/31868#31965 · In reply to: #31915 Pierre wrote: > > > > […] > > It really depends on the architecture. Using a precision of 10 should > put you on the safe side, at least for the common architecture (intel, > amd and ppc). > Yes - you are right thanks. I'm currently testing that the answer is within +/- 1.0E-10 of what I expect - that works on the processor architectures that I have access to. I guess I'll find out what happens on the others wheh I check the test cases in :-). > --Pierre