commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject [math][functor] MathBeans was: (Re: [math] ... just one more reference...)
Date Sun, 19 Oct 2003 20:47:33 GMT
Initially, I'd thought one would like to use Functor's BinaryFunction 
and UnitaryFunction interfaces as the foundation of such Functional Math 

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:

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

/* 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(
			/* ... */

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 

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 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
> 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

Mark Diggory
Software Developer
Harvard MIT Data Center

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message