How much of these objects are actually already in common-math ? I have'nt seen so much yet.None really, our focus has been on algorithm development.
Well, there's at least Matrix (even incomplete)...
Writing an evaluator for such functions is really not a big deal if one has objects for each functions. I've recently done this in a dumb way for +-*/ and would know how to do this more generically.Yes, but I would have an interest in attempting to write this with some performance efficiency in mind. Its a tough call, sure one could write separate functor classes +=*/ but we come up against consuming alot of memory and processor to achieve something that is computationally simple.
Another thought I have is to actually use something like BCEL to generate Java Byte Code directly from the XML Parsing or Jelly enterpreting. I've done this before in another Jelly taglib project.
http://repast-jellytag.sourceforge.net
I actually have a BCEL tag that creates classes and methods using tags with bodies that can basically be any BSF script. This would provide a means to generate optimized "equation objects" from xml.
In fact one could write an intermediary library of functional objects (like what we are talking about), and then use BCEL to optimize that object hierarchy at runtime.
Well, you wouldn't remove the class-loading memory hog, or would you? And for speed, well, I'm not so sure... does such a library actually compile an expression like (in Java) Math.abs(Math.sin(3*x^2+5)) into an in-line sequence of bytecodes (like the compilation of this java expression) ??
If yes, then indeed, there could be some interest... (it's basically like compiling a script).
Performance measurement should be made in some way... I am not very clear how much overhead such method calls actually are.
There's a kind of related problem: what if I'm interested into a manipulation of such a formula ? (e.g. integrate it).
Symbolic computation systems tend to have this in memory in a very similar fashion to an XML-tree actually...
Is this of interest ? I would set myself to work... for sure...See below, I think we need to consider the home of such a thing as this. I also think that a game plan is needed (not that experimentation is not welcome, go to town man).
Is it of interest to depend on xml things ?
JAXP, keep anything xml independent of implementation. In fact there are an number of options from JAXB, Jelly, to Digester for processing XML into objects.
Sure, sure, sure... (except jaxp has this ugly license, but... ah well) Indeed quoting specific parsers wasn't so elegant...
I think we're looking at a project that is quite separate of the actually Jakarta Commons Math component. Not to suggest I'm not interested (I am). Its just that math is a base library to be used in other components and I don't think we should place higher level concepts (like this) directly into it without some concensus.
Higher level like compilation, I would agree it's kind of separate... but having generic formulae support (kind of generic) within jakarta-commons-math makes some sense to my taste.
It should be possible to keep the compilation vs. introspectable-data-structures dichotomy separate from the actual user-side or ? Interfaces should be enough for that...
Let's try to be a bit more concrete, what might be wished:
- a set of classes that can compute elementary formulae evaluations (with a back-door to being inspected). Evaluation should probably be limited to float/int/bigint for now... (fractions?)
This should probably include at least common one-variable functions (the name "special functions" is kind of weird in the package) at first.
- a parser for OpenMath, MathML, xxx? to be able to create at least function objects from such expressions. Be it a taglib or anything else, this is actually pretty unimportant, or ?
Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
