Re: Puzzling error from cpan testers
On Tue, May 05, 2009 at 03:05:49PM -0400, David Golden wrote: Yikes. You must have missed Test::Number::Delta ... Harr! That'll teach me to read the whole thread before replying! -- David Cantrell | Enforcer, South London Linguistic Massive Irregular English: you have anecdotes; they have data; I have proof
Re: Puzzling error from cpan testers
On Tue, May 5, 2009 at 6:02 AM, David Cantrell da...@cantrell.org.ukwrote: On Sun, May 03, 2009 at 12:23:27PM -0700, Bill Ward wrote: On Sun, May 3, 2009 at 12:18 PM, Andy Armstrong a...@hexten.net wrote: On 3 May 2009, at 20:07, Bill Ward wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html [...]Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts? Yeah, that's floating point. There can be a difference between the two values that's too small to display but big enough to make them non-equal. '==' is /always/ risky with FP values. You should instead check for the value being within an acceptable range. Do you think I should change it to use eq in the test? It may work, or it may not. If it works - in the sense of making the test failure go away - then I would expect it to bite someone later when they just happen to hit upon a number where the floating point rounding error goes the other way. Check that it's in an acceptable range. Perhaps I should stringify and then re-numberify the value inside round() instead?
Re: Puzzling error from cpan testers
Howdy,
It may work, or it may not. If it works - in the sense of making the
test failure go away - then I would expect it to bite someone later when
they just happen to hit upon a number where the floating point rounding
error goes the other way.
Check that it's in an acceptable range.
I heartily agree with this. Math::GSL has thousands of tests like
this, which is why Math::GSL::Test
has a number of easy-to-use functions to do this.
Perhaps I should stringify and then re-numberify the value inside round()
instead?
I very much recommend that you look at is_similar() in
Math::GSL::Test, it has implemented at least a
few wheels that you are destined to want:
is_similar($x,$y;$eps,$similarity_function)
is_similar($x,$y);
is_similar($x, $y, 1e-7);
is_similar($x,$y, 1e-3, sub { ... } );
Return true if $x and $y are within $eps of each other, i.e.
abs($x-$y) = $eps
If passed a code reference $similarity_function, it will pass $x and $y
as parameters to it and will check to see if
$similarity_function-($x,$y_) = $eps
The default value of $eps is 1e-8. Don't try sending anything to the
Moon with this value...
You can use the $similarity_function to implement relative error
bounds and there is also a is_similar_relative() wrapper. All of these
functions take array references of floating point values and map over
them. The reason these methods are in Math::GSL::Test is because they
also correctly handle GSL_NAN correctly, so you can ignore those bits.
Cheers,
--
Jonathan Leto
jonat...@leto.net
http://leto.net
Re: Puzzling error from cpan testers
On Tue, May 5, 2009 at 2:58 PM, Jonathan Leto jal...@gmail.com wrote: I very much recommend that you look at is_similar() in Math::GSL::Test, it has implemented at least a few wheels that you are destined to want: Yikes. You must have missed Test::Number::Delta when you were writing that. On CPAN since 2005. I originally called it Test::Float and got argued into a proper hierarchical name, which is probably why no one seems to know it exists. Synopsis: # Import test functions use Test::Number::Delta; # Equality test with default tolerance delta_ok( 1e-5, 2e-5, 'values within 1e-6'); # Inequality test with default tolerance delta_not_ok( 1e-5, 2e-5, 'values not within 1e-6'); # Provide specific tolerance delta_within( 1e-3, 2e-3, 1e-4, 'values within 1e-4'); delta_not_within( 1e-3, 2e-3, 1e-4, 'values not within 1e-4'); # Compare arrays or matrices @a = ( 3.14, 1.41 ); @b = ( 3.15, 1.41 ); delta_ok( \...@a, \...@b, 'compare @a and @b' ); # Set a different default tolerance use Test::Number::Delta within = 1e-5; delta_ok( 1.1e-5, 2e-5, 'values within 1e-5'); # ok # Set a relative tolerance use Test::Number::Delta relative = 1e-3; delta_ok( 1.01, 1.0099, 'values within 1.01e-3');
Re: Puzzling error from cpan testers
Thanks David. This is a nice module, but overkill for my needs and I'd rather not make people install more CPAN modules than they have to. Looks like the key thing is this line: $ok = abs($p - $q) $epsilon; I'll incorporate that bit into my test suite for Number::Format. On Tue, May 5, 2009 at 12:05 PM, David Golden xda...@gmail.com wrote: On Tue, May 5, 2009 at 2:58 PM, Jonathan Leto jal...@gmail.com wrote: I very much recommend that you look at is_similar() in Math::GSL::Test, it has implemented at least a few wheels that you are destined to want: Yikes. You must have missed Test::Number::Delta when you were writing that. On CPAN since 2005. I originally called it Test::Float and got argued into a proper hierarchical name, which is probably why no one seems to know it exists. Synopsis: # Import test functions use Test::Number::Delta; # Equality test with default tolerance delta_ok( 1e-5, 2e-5, 'values within 1e-6'); # Inequality test with default tolerance delta_not_ok( 1e-5, 2e-5, 'values not within 1e-6'); # Provide specific tolerance delta_within( 1e-3, 2e-3, 1e-4, 'values within 1e-4'); delta_not_within( 1e-3, 2e-3, 1e-4, 'values not within 1e-4'); # Compare arrays or matrices @a = ( 3.14, 1.41 ); @b = ( 3.15, 1.41 ); delta_ok( \...@a, \...@b, 'compare @a and @b' ); # Set a different default tolerance use Test::Number::Delta within = 1e-5; delta_ok( 1.1e-5, 2e-5, 'values within 1e-5'); # ok # Set a relative tolerance use Test::Number::Delta relative = 1e-3; delta_ok( 1.01, 1.0099, 'values within 1.01e-3'); -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Puzzling error from cpan testers
Howdy, Yikes. You must have missed Test::Number::Delta when you were writing that. On CPAN since 2005. I originally called it Test::Float and got argued into a proper hierarchical name, which is probably why no one seems to know it exists. Synopsis: No, I saw your module, but I needed to correctly deal with 'NaN' in a portable way via gsl_nan(). I agree with you that you module *should* be used by a lot more people who just '==' doubles and hope for the best. Cheers, -- Jonathan Leto jonat...@leto.net http://leto.net
Puzzling error from cpan testers
For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html # Failed test 'pi with precision=6' # at t/round.t line 18. # got: 3.141593 # expected: 3.141593 # Failed test 'precision=-2' # at t/round.t line 24. # got: 123500 # expected: 123500 # Looks like you failed 2 tests of 16. t/round.t Here are the test cases in question: cmp_ok(round(PI,6), '==', 3.141593, 'pi with precision=6'); cmp_ok(round(123456.78951, -2), '==', 123500, 'precision=-2' ); Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts?
Re: Puzzling error from cpan testers
On 3 May 2009, at 20:07, Bill Ward wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html # Failed test 'pi with precision=6' # at t/round.t line 18. # got: 3.141593 # expected: 3.141593 # Failed test 'precision=-2' # at t/round.t line 24. # got: 123500 # expected: 123500 # Looks like you failed 2 tests of 16. t/round.t Here are the test cases in question: cmp_ok(round(PI,6), '==', 3.141593, 'pi with precision=6'); cmp_ok(round(123456.78951, -2), '==', 123500, 'precision=-2' ); Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts? Yeah, that's floating point. There can be a difference between the two values that's too small to display but big enough to make them non- equal. '==' is /always/ risky with FP values. You should instead check for the value being within an acceptable range. -- Andy Armstrong, Hexten
Re: Puzzling error from cpan testers
On Sun, May 3, 2009 at 12:18 PM, Andy Armstrong a...@hexten.net wrote: On 3 May 2009, at 20:07, Bill Ward wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html [...]Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts? Yeah, that's floating point. There can be a difference between the two values that's too small to display but big enough to make them non-equal. '==' is /always/ risky with FP values. You should instead check for the value being within an acceptable range. Do you think I should change it to use eq in the test?
Re: Puzzling error from cpan testers
On Sun, May 3, 2009 at 3:07 PM, Bill Ward b...@wards.net wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html # Failed test 'pi with precision=6' # at t/round.t line 18. # got: 3.141593 # expected: 3.141593 That's my report. Perl is compiled with -Dusemorebits (64int-ld) and is thus using long doubles. That tends to trip up direct comparisions of floating point. For floating point comparison, I usually recommend Test::Number::Delta. However, given that your module is about formatting stuff, maybe the best approach is forcing string comparison. From a quick test -- using 'eq' instead of '==' in your modules passes tests on my system. -- David
