Re: Math_Function

From: Date: Fri, 27 Jan 2006 16:04:48 +0000
Subject: Re: Math_Function
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-41110@lists.php.net to get a copy of this message
Hi all, --- Etienne Kneuss <webmaster@colder.ch> wrote: > Hi, > > Ants Aasma a �crit : > > As I see it, a defined function is just an expression with defined > > parameter order. Eg. the expression "x+y*z" has parameters/free > > variables x,y,z and can be considered to be a function f(x,y,z) = x+y*z. > Extending it to expressions would allow equations, and vector/matrix > representation (which is not something needed, but it would be a plus). Indeed, you could think of a expression parser that could be used for a symbolic algebra package, or by a user application that could parse a system of simultaneous equations, then create the appropriate matrix and obtain the solution. > > I'm with you on lightweight, well defined packages, but derivatives > > just fit so well into function/operator definition classes. Every > > function has a derivative and the derivative is specific to that > > function. The overhead, at least now, is minimal - just one relatively > > simple function to compile. I don't see any real reason to factor out > > that functionality. Knowledge about ones derivative fits very well > > into a function definition. Factoring it out creates a parallel > > class/logic/information hierarchy, whatever way you implement it, and > > that just seems to me as a bad code smell. > There is quite a big problem with the design you currently use : its not > extensible in functionalities. We're only able to extend the defined > functions' list. Adding new functionalities that are function dependent > would require a modification of every functions' class. So either we > have a Math_Function package that already implements everything (which > is not something wanted), either we have an isolated package that is not > extensible. I'd rather have a small performance hit and have an extensible package than having a very fast one that it is not (of course having my cake and eat it too would be ideal :-). Remember that the philosophy of making reusable components, is to try and make them so the user/developer can pick an choose the bits she needs to do her work. We could also argue that functions are just one little piece of a bigger area of math expression, even for the ones related to functions, there are functionals[1], functors[2], and other strange beasts. [1] http://en.wikipedia.org/wiki/Functional_(mathematics) [2] http://en.wikipedia.org/wiki/Functor > Compared to Math_Derivative, the biggest advantage is a good looking > design, which doesn't in fact provide many advantages. Talking about a > novice user, I think its easier for him to implement a new function just > by giving the derivative expression, than having to create a class for it. > > I think it would be better to consider another design, that would > probably contain some parallel class/logic/information that can't IMO be > avoided if the goal is to have extensible, small and surgical packages. > (quoting Bertrand) > > If you have any good ideas how would a derivative operation package > > look like with a high-level expression datastructure, I'd love to hear it. > Well, I will try to imagine an effective design from a different point > of view than yours. And we will compare :) > > > I would really like to have other devs into this thread ! The one-package-to-rule-them-all would not be applicable to at least one of the mathematical beasts mentioned above (functionals), because then it will have to have to duplicate some functionality (perhaps) to support having a function to which functions are its domain (a functional), and also have the corresponding derivatives, integrals, etc. Now, let's not forget other things like Wronskians and other things that have made lose sleep (and some sanity) to math students everywhere. Modular and lightweight is good, up to a point, discussing alternative approaches helps us refine things and get better, so we do not get to either extreme. Cheers. -- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Web site: http://www.castagnetto.org/ Research: http://metallo.scripps.edu/ PEAR stuff: http://pear.php.net/user/jmcastagnetto __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

« previous php.pear.dev (#41110) next »