Re: Algorithm::RootFind Request for Comments
On Tuesday 15 February 2005 09:22, C. Chad Wallace wrote: Spencer Ogden wrote: I have a collection of functions for using numerical computation to approximate the roots of arbitrary functions. It is a function library, no OO. I am wondering where to put it, either Algorithm:: or Math:: I think Math::RootFind would be best, since the package is of specifically math-oriented algorithms. My first impression of the name Algorithm::RootFind was that it might find the root of a binary tree or something similar. I second that. Math::RootFind would be better. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Knuth is not God! It took him two days to build the Roman Empire.
Re: Algorithm::RootFind Request for Comments
OK, Math::RootFind it is. One more question, on interface: All of the algorithms have two parameters, e (as in epsilon) and max_iter, which set precision and max run-time respectively. They have reasonable defaults, and probably won't be changed often, so I am loathe to make them function arguments. So I have made them package globals with accessors to alter them. The undesirable effect of course is that altering them in one part of your program effects all uses of the algorithm, which may not be intended. It looks like this. bisection( \func, -10,10 ); #Normal call with defaults epsilon(.01); max_iter(10); bisection( \func, -10, 10); # From now on all calls will use the above e and max_iter I still think putting them as function arguments would be redundant in most cases, although maybe optional arguments would be best (just thinking out loud). Any other suggestions as to how to handle sort of 'config' settings? Regards, Spencer Ogden Shlomi Fish wrote: On Tuesday 15 February 2005 09:22, C. Chad Wallace wrote: Spencer Ogden wrote: I have a collection of functions for using numerical computation to approximate the roots of arbitrary functions. It is a function library, no OO. I am wondering where to put it, either Algorithm:: or Math:: I think Math::RootFind would be best, since the package is of specifically math-oriented algorithms. My first impression of the name "Algorithm::RootFind" was that it might find the root of a binary tree or something similar. I second that. Math::RootFind would be better. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Knuth is not God! It took him two days to build the Roman Empire.
Re: Algorithm::RootFind Request for Comments
David Landgren writes: Spencer Ogden wrote: Any other suggestions as to how to handle sort of 'config' settings? Use named parameters. bisection( \func ); bisection( \func, min = -100 ); bisection( \func, min = 20, max = 40 ); That's probably what I would do. It's still irritating if you want to make many calls to bisection all with the same (non-default) values of epsilon and max_iter, because then you have to specify them on every call, or use the global accessors to change the package variables, changes which will still be in affect elsewhere in your program (or in other modules, or in other programs you're sharing a mod_perl process with, or whatever). In some ways it'd be better to encourage people to modify the package variables directly, rather than using accessor functions, because then the changes can be localized: local $Math::RootFind::epsilon = 0.01; Another option when you want some data to be associated with some function calls is to put the data into an object and make method calls on it: my $thingy = Math::RootFind-new(max_iter = 12); $thingy-bisection(\func, 20, 40); For the typical case, using the default values, you can avoid constructing an object and just use a class method: Math::RootFind-bisection(\func, 20, 40); But while that solves the problem I don't like it: there are many modules on Cpan which provide similar OO interfaces, and I find them annoying to use. Having to call a class method when what you want is a function is rather tedious, and a little misleading. In this particular case we've avoided the unusual case of having to specify optional params multiple times at the expense of having to spell out the full class name on all calls in the usual case -- that's hardly a win. That can be addressed by making bisection be a hybrid that works as either an instance method call or a direct function call that can be imported, like CGI::param is. That's kind of messy though, and I'm not convinced the complexity is worth the effort: merely documenting the ways in which your module can be used then makes it look much more complicated than it actually is, which can be offputting. And the other reason why I don't like OO here is that I want an object to be modelling something tangible. Here we can have a Math::RootFind, which doesn't really make sense, and I called the variable above $thingy because there isn't an obvious name for what it represents; that is often a red flag that such an entity is representing an artificial entity. Smylers
