Re: Math_Function
| From: | Jesus M. Castagnetto | 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