commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] ... just one more reference...
Date Thu, 16 Oct 2003 13:08:16 GMT

Paul Libbrecht wrote:

> Mark R. Diggory wrote:
>> Yes, Dreams... ;-) I've actually had thoughts about a Jelly based 
>> MathML/OpenMath taglibrary which would evaluate MathML/OpenMath XML 
>> fragments, generating a series of Java Objects representing the 
>> equation expressed in the syntax. Ideally, if a functional model was 
>> applied properly, such "equations" could be "evaluated" to return values.
> Cool...
> 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.

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

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

> If we choose not to use 
> xerces (e.g. Saxon's AElfred, or the one bundled in xmlrpc) then it's 
> not a big deal but if we choose xerces it makes it quite enormous...

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.

> Are there plans for subprojects ? I think it could make sense... 
> especially those ones based on external dependencies (eg. input-editors, 
> displayers) or importing using classical OpenMath libraries (e.g. the 
> one of RIACA which can communicate to symbol-math systems).
 > Cool to see this enthusiastically!
 > Paul

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.

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message