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
Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
Hi wise Perl authors: I've been building some Perl packages for Debian. I've noticed in the course of this that dh-make-perl (our preferred script for transforming Perl distributions into Debian packages) prefers Makefile.PL over Build.PL. One problem this has caused is that a Makefile is created which is not removed when 'perl Build clean' is run. Now, Makefile.PL via Module::Build::Compat actually runs Build.PL the first time, so the Makefile expects 'Build' to already exist. The next time the module is built, 'make' is run, which in turn triggers 'perl Build', but this no longer works since Build.PL has not been run yet (so there is no Build). The real question at hand here is: for modules that provide both a Makefile.PL and Build.PL, which should be preferred? More than that, from the perspective of CPAN authors, is it even useful to provide both? Now that Module::Build is a core module, maybe only a Build.PL should be included. Add to this some complication from Module::Install, which also uses Makefile.PL. So in that case maybe Makefile.PL is preferred (for Module::Install to do its thing) rather than Build.PL. (On the other hand, I don't think I've seen modules that mix both M::I and M::B, so in the wild this will probably not be a problem) What does everyone else think? I look forward to reading what other authors have to say about this. Cheers, Jonathan
Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
The way I've interpreted that in my own auto-build scripting is that if Build.PL exists, the module author is probably a Module::Build user who is only providing a Makefile.PL grudgingly for the sake of those who haven't installed Module::Build, and thus I figure that if there's any difference between the two .PL files, probably Build.PL is the one the author is more invested in. On Tue, May 5, 2009 at 7:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Hi wise Perl authors: I've been building some Perl packages for Debian. I've noticed in the course of this that dh-make-perl (our preferred script for transforming Perl distributions into Debian packages) prefers Makefile.PL over Build.PL. One problem this has caused is that a Makefile is created which is not removed when 'perl Build clean' is run. Now, Makefile.PL via Module::Build::Compat actually runs Build.PL the first time, so the Makefile expects 'Build' to already exist. The next time the module is built, 'make' is run, which in turn triggers 'perl Build', but this no longer works since Build.PL has not been run yet (so there is no Build). The real question at hand here is: for modules that provide both a Makefile.PL and Build.PL, which should be preferred? More than that, from the perspective of CPAN authors, is it even useful to provide both? Now that Module::Build is a core module, maybe only a Build.PL should be included. Add to this some complication from Module::Install, which also uses Makefile.PL. So in that case maybe Makefile.PL is preferred (for Module::Install to do its thing) rather than Build.PL. (On the other hand, I don't think I've seen modules that mix both M::I and M::B, so in the wild this will probably not be a problem) What does everyone else think? I look forward to reading what other authors have to say about this. Cheers, Jonathan -- 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: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
On Tue, May 5, 2009 at 10:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Add to this some complication from Module::Install, which also uses Makefile.PL. So in that case maybe Makefile.PL is preferred (for Module::Install to do its thing) rather than Build.PL. (On the other hand, I don't think I've seen modules that mix both M::I and M::B, so in the wild this will probably not be a problem) For a brief time, M::I would also create a Build.PL that ran Makefile.PL that ran M::I. That doesn't happen anymore. (There might be a dist or two that still has it. E.g. Yahoo-Photos-0.0.2). I would say that if Build.PL exists, you should assume that to be the preferred build tool. -- David
Arguments checker module
Is anyone aware of any modules that will check subroutine arguments? I can think of two similar features of Perl, but neither is quite right: 1. Prototypes (perlsyn) - put something like ($$@) after your subroutine declaration - but doesn't work for object methods and a few other cases. Plus, doesn't give you the ability to name the arguments and doesn't support argument-based overloading. 2. Getopt::Long - check for argument value types, illegal arguments, etc. - but doesn't allow for mandatory options (sounds like an oxymoron, but very common when passing arguments in a hash form to a subroutine) or validating nested data structures. I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? -- 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: Arguments checker module
On Tue, May 05, 2009 at 07:51:09PM -0700, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Params::Validate does everything but nested data structures. Declare::Constraints::Simple does everything. Data::FormValidator does everything. MooseX::Types does everything and does it best. There are a lot more of these. I'm surprised you haven't seen them on CPAN. hdp.
Re: Arguments checker module
On Tue, 5 May 2009, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Please don't write yet another one. Params::Validate Params::Util (sort of a validator) Moose + MooseX::Params::Validate MooseX::Method::Signatures Perl6::Signature and probably five dozen more. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Arguments checker module
On Tue, May 5, 2009 at 7:55 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Tue, May 05, 2009 at 07:51:09PM -0700, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Params::Validate does everything but nested data structures. Declare::Constraints::Simple does everything. Data::FormValidator does everything. MooseX::Types does everything and does it best. There are a lot more of these. I'm surprised you haven't seen them on CPAN. Thanks for the recommendations. I didn't think to look under any of those names.
Re: Arguments checker module
On Tue, May 5, 2009 at 7:55 PM, Dave Rolsky auta...@urth.org wrote: On Tue, 5 May 2009, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Please don't write yet another one. I will if none of them meet my needs. Params::Validate Params::Util (sort of a validator) Moose + MooseX::Params::Validate MooseX::Method::Signatures Perl6::Signature and probably five dozen more. Thanks for the suggestions. I'm not interested in being locked-in to a framework like Moose, so I won't even consider those. Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate?
Re: Arguments checker module
On Tue, May 05, 2009 at 08:04:35PM -0700, Bill Ward wrote: I'm not interested in being locked-in to a framework like Moose, so I won't even consider those. http://search.cpan.org/~drolsky/Moose-0.77/lib/Moose/Util/TypeConstraints.pm#Use_with_Other_Constraint_Modules Moose's type constraints subsume pretty much anything else. What's the lock-in you're worried about? Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? I did that once, if it helps. http://search.cpan.org/~hdp/Params-Validate-Micro-0.032/lib/Params/Validate/Micro.pm hdp.
Re: Arguments checker module
On Tue, May 5, 2009 at 8:27 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Tue, May 05, 2009 at 08:04:35PM -0700, Bill Ward wrote: I'm not interested in being locked-in to a framework like Moose, so I won't even consider those. http://search.cpan.org/~drolsky/Moose-0.77/lib/Moose/Util/TypeConstraints.pm#Use_with_Other_Constraint_Moduleshttp://search.cpan.org/%7Edrolsky/Moose-0.77/lib/Moose/Util/TypeConstraints.pm#Use_with_Other_Constraint_Modules Moose's type constraints subsume pretty much anything else. What's the lock-in you're worried about? Just a philosophical objection to frameworks. I like Perl's OO the way it is, thanks. Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? I did that once, if it helps. http://search.cpan.org/~hdp/Params-Validate-Micro-0.032/lib/Params/Validate/Micro.pmhttp://search.cpan.org/%7Ehdp/Params-Validate-Micro-0.032/lib/Params/Validate/Micro.pm I'll take a look at that. -- 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: Arguments checker module
On Wed, May 6, 2009 at 12:04 AM, Bill Ward b...@wards.net wrote: Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? Have you looked at Method::Signatures?
