Mark,
Aiming at providing integration capabilities (or solving capabilities)is probably quite big-shot... (though Apache foundation has the power create these, maybe) but it should be possible, indeed. I like the idea of a standardized object-tree...
For the code excerpt I would have the following comments:
- the setArguments(Object[] xx) is really heavy, I would rather work with java.util.List....
- there may be a "context" missing: these beans don't seem to be able to talk to their parents (although it would make sense I think). Having a notion of context might help, something where you could put that we are working on this field (e.g. complexes, e.g. fractions)...
- finally, the XML to beans mapping may be a dangerous slope... at least it might be dangerous to make it candidly. I would suggest using at least Jelly's flexibility to achieve OpenMath or MathML reading capabilities.
I like the idea. The name... well, I don't think we need much more than commons-math and it makes sense to make it live in there I think. The external plugs (like OpenMath/MathML reading, like communication to other systems (e.g. using Mathematica J/Link) should be done in subprojects, I think.
I am not so sure how different this all is from, say HartMath or any other computer-algebra system. But, indeed, I know none that has a good license (HartMath is GPL, parts of it will be LGPL) and are in Java...
Paul
Mark R. Diggory wrote:
Initially, I'd thought one would like to use Functor's BinaryFunction and UnitaryFunction interfaces as the foundation of such Functional Math objects.
http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/UnaryFunction.html
http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/BinaryFunction.html
However, the whole concept of taking these as objects and plugging them together in "runtime", or evaluating a group of them to accompish a task like "Integration" becomes problematic when they are only connected together during the "evaulate" method or during thier construction. See:
http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/core/composite/Or.html
http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/core/composite/And.html
for some examples of this style.
I think one could just stick with the Function interface for the time being, use bean properties to set the various sides of the function, and provide a no arg constructor
http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/Function.html
/* for summary Functions (Summation ...) */ interface MultiMathBean extends Function {
public void setArguments(Object[] objects);
}
/* for binary Functions ( +*/- ... ) */ interface BinaryMathBean extends Function {
public void setRightArgument(Object right);
public void setLeftArgument(Object left);
}
/* for uniary functions (sin, cos, tan, ...) */ interface UniaryMathBean extends Function {
public void setArgument(Object object);
}
for example:
class Sin implements UniaryMathBean {
Object object;
public void setArgument(Object object){ this.object = object; }
public Object evaluate(){ if(object instanceof Number){ return Math.sin(((Number)object).doubleValue()); }else if ( object instanceof Function){ return Math.sin( ((Number)( (Function)object ).evaluate() ).doubleValue()) }else{ /* ... */ } } }
Sin sin = new Sin() sin.setArgument(new Double(1.0)); Object o = sin.evaluate();
Some may feel that this gets messy quickly, there alot of get/set going on, but ultimately the goal isn't about making pretty or light java code, it is more to provide runtime manipulation of the connections such that you can easily manipulate the inter-relations of the bean objects themselves.
Really the nature of this whole concept is to design a library of "MathBeans" that can be easily manipulated in a BeanBox or other application. So, there's a possible project name.
-Mark
Mark R. Diggory wrote:
Paul Libbrecht wrote:
Mark R. Diggory wrote:
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.
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?
We're talking about taking existing class objects and optimizing into a new class hierarchy, then inserting them back into the classloader. So no, the classloader instantiation is still there. I suspect that other generic tools like gcj could be used to optimize that aspect further.
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) ??
Its less formal, BCEL lets you manipulate the bytecode, how one manipulates the bytecode is upto their own need.
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.
Thinking in Java
http://www.codeguru.com/java/tij/tij0203.shtml
This is probably the best resource to date that I've found about the cost of basic operations in java.
It would be nice to provide some JUnit like classes to show these tests. I was hoping that with maven, we could possibly write a pluggin that does a sort of performance test, generating an xdoc of the results that can be used in the site generation. Ideally, one could write performance tests for any library and output the results to xdoc or any other format of interest.
There's a kind of related problem: what if I'm interested into a manipulation of such a formula ? (e.g. integrate it).
This is a "fun" idea.
Symbolic computation systems tend to have this in memory in a very similar fashion to an XML-tree actually...
Yes, I suspect your referring to the idea that one could manipulate instances of these objects to "plug" them into each other via things like get/set methods or bean properties. This would open up development of these "equations" on a number of "javabean oriented" visual tools.
Is this of interest ? I would set myself to work... for sure...
Is it of interest to depend on xml things ?
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).
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 some thoughts about modularity are important, I've worked in a number of projects where the boundaries between dependencies tends to get out of control. I would suggest first working on an object model as a core, then possibly a separate package for serializing/deserializing things. I would almost suggest reviewing the commons components or other libraries to really determine if xml --> object --> xml is already available in a generic library of some sort.
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...
Yes, I tend to agree, the user works with these classes/objects, the framework deals with optimization capabilities transparent to the user.
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.
I really suggest we look over the functor component in the commons sandbox for a starting point, I suspect we will find a strong starting point here within functor to extend upon in this direction.
- 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 ?
I think we're really on the same page here. Could you post your examples of +*/- so we can get an idea of the design so far?
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
