Re: Math_Function

Bonsoir, Sorry, I missed to answer that thread. Also, my diplomacy skills are well known to be very low. In anycase, Math category will be efficient only if packages *do* communicate. Pear better tries to offer small, chirurgical packages. I will never trust some "I do it all" package, pear users want to implement *only* what they need. I worked along with Etienne since monthes untill he succeded in that proposal: http://pear.php.net/pepr/pepr-proposal-show.php?id=337 which is now resonnabily on "Call for votes" As I know this work, nothing is closed for nothing Peculiarly, it's some evidence we need to tailor the "expressions" No war, I like Math à+ -- toggg Ants Aasma wrote:

Etienne Kneuss wrote:

Arpad Ray wrote :

I missed the original comment but I absolutely agree that we need a more general package, akin to CPAN's Math::Symbolic.

I agree with that, we should have a package that handles math expressions, to reduce the redundant parsing work performed in packages. Now, including derivatives or not in such a package is another question, I would rather like having separated packages for each operations based on the "expression" package, than everything implemented in it. That would probably save it from too much overhead (Math_Function is currently 2x slower than Math_Derivative, for a less simplified result).

I included derivatives in the expression package because it just seemed so natural. Having derivatives as a separate package means basically making a parallel class hierarchy to available mathematical functions. Regarding performance overhead, there are a *lot* of optimizations available in the current implementation. I just did pretty much the minimum necessary to make it work. Simplification should probably be factored out into a separate package. Probably same for the RPN parser. <braindump> Currently my idea is to create following packages: Math_Expression/Function

    Base datatype for algebraic expressions held as a tree of
    objects. I have to think about the expression/function thing.
    The difference between them is that a function has as a minimum
    the requirement for information about the order of parameters.
    Rendering functionality may be implemented in this package or
    split out into a separate package mirroring the class hierarchy.
    Rendering needs knowledge about precedence, associativity and
    maybe some other properties of functions.

Math_RPN(2)

    Encapsulates parsing knowledge. Probably should use a driver
    based design with (optionally configurable) drivers for textual
    notation and others as need arises. I don't a lot about it, but
    perhaps a MathML driver can be considered. Textual driver needs
    to have knowledge of operator representation, precedence and
    associativity.
    I'll investigate if the currently available Math_RPN package
    could and should be extended to provide the needed parsing
    functionality.

Math_Simplification

    This should encapsulate knowledge about simplification
    algorithms. Needs intimate knowledge of implemented functions.

Math_Numerical_RootFinding

    Look into if and how functionality should be added to provide
    a good API for numerical rootfinding with Math_Function based
    functions.

Image_Graph

    Look into making a nice API for using Image_Graph to plot
    Math_Function. Simple plots aren't too difficult even now with
    Image_Graph_Dataset_Function and Image_Graph_Dataset_Vector
    classes. Image_Graph doesn't yet have any support for 3D graphs,
    so multidimensional functions can only be plotted over a line.
    I don't know if this necessitates a separate API or
        $func->substitute('x', $linexfunc);
        $func->substitute('y', $lineyfunc);
    will be enough.

I'm also thinking about making a general driver based package that implements different algebras. Integer, floatingpoint, arbitrary precision, etc. I actually need the first one to factor out a dependency on ext/gmp from two of my packages. (one is implementation of Blum, Blum & Shub pseudo random number generator, other is an implementation of Shamirs secret sharing scheme) I'll look into how this factors into Math_Function API. If the API and/or implementation doesn't get out of hand, we can have a system where functions can be evaluated over Galois fields for example. </braindump> I'll try to work out a public API specification for the packages. I'll post it here in day or two to get some comments. If anyone has any comments, requirements, ideas, please make yourself heard and I'll take it into account. Ants Aasma