commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] ... just one more reference...
Date Sun, 19 Oct 2003 17:58:37 GMT


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

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message