commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: [math] ... just one more reference...
Date Thu, 16 Oct 2003 19:25:13 GMT
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.
> 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.
> 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...
>> 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 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 ?


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

View raw message