Re: Math_Function

Etienne Kneuss wrote:

IMO, we shouldn't focus on math functions, but extend it to math expressions, that would increase the applications' possibilities. So Math_Function, which is now based on functions, wouldn't fit as it is right now.

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.

I imagined the Math_Expression package more like a tokenizer/lexer that just interpret low level expression (string) into a high level format (which is still to discuss).

I'd prefer that the tokenizer is the string->RPN converter and Math_Expression just knows how to build the high level format from RPN, mapping operators and functions to appropriate classes.

I included derivatives in the expression package because it just seemed so natural.

Getting the derivative of an expression is just an operation among others (integrals, equations, manipulation, ...), so I *really* think this shouldn't be implemented in the base Expression package.

Having derivatives as a separate package means basically making a parallel class hierarchy to available mathematical functions.

I think we can get over it using an appropriate design. And somebody that just wants to use a children package, say Simplify, wouldn't have to carry derivative support.

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. 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. To get an idea, how basic the derivative implementation is, look at the buildDerivative() function in my implementation. IMHO it pretty much minimally encapsulates knowledge about a functions derivative.

Talking about applications, I would really like to have a package that draws an expression, and create an image of it. It would make life easier for math publishers.

That can be one of the rendering drivers for Math_Expression. On first glance Image_Canvas can be used as a backend, giving automatically GD, SVG and PDF support. With good well-defined components, sky is the limit. :) Ants