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][functor] MathBeans was: (Re: [math] ... just one more reference...)
Date Tue, 21 Oct 2003 16:33:57 GMT
Attached is a small example of what I've written up as a "rough draft" 
of sorts. You are welcome to take or leave it. I've named the build 
"Archimedes" which I thought was somewhat appropriate.


Paul Libbrecht wrote:
> 
> 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...
> 

Yes, I think there are many directions something like this can go. Which 
is why I'm not sure that commons is the best location for it in the long 
run. Specifically because one has to ask the question of how does such 
code relate to the "server" environment and specifically Servlet 
Engines. Its more of an application than a common utility.

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

It was strictly an example, I've actually started to find that these 
"set/get" properties are actually outside of any interfaces at this 
point and free to variation.


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

Valid idea, I'm not sure of its requirement, I tend to think of these 
objects as a hierarchy similar to DOM. Maybe in such a case, DOM like 
methods would prove useful.

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

True, for myself, XML helps me think about the technical implementation 
of the API in relation to another well design API that has been widely 
accepted. Just for clarities sake, I think in terms of implementation, 
the technologies XML and Object should stay very separate. Much in the 
way that Model and View stay separated in MVC.
> 
> 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. 

Not attached to the name, I just like to find interesting names for 
projects (as you can see).

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

true, but if we want subprojects or modules, then this definitly starts 
to fall outside of the commons, specifically because commons are modules 
that are each just one jar, subprojects suggest more than one jar.

Maybe we should go to the incubator and attempt to set "subprojects" or 
"applications" of the library up there.

> 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

I hadn't seen HartMath before. Its interesting and accomplishes much of 
what we're discussing. I found some parts of the source useful as 
examples, yet others I found very cryptic.

In terms of subjects like bytecode optimization and BCEL. I really see 
three avenues of interest that could be explored.

1.) BCEL could be used to "optimize" the bytecode for an Object 
Hierarchy representing a math expression. The nature of this 
optimization has lots of room for discussion.

2.) BCEL could be used to manipulate the bytecode for an Expressions 
Object Hierarchy to accomplish tasks like Integration/Differentiation.

3.) And this is sort of a "subpart of (1) and (2) capabilities : BCEL 
could be used to manipulate ordinary byte code for regular java 
operands/variable. For example:

/*
Expression is a base class for holding the the Object Hierarchy or 
bytecode fragment. Similar to what "Document" is to DOM, Element Objects 
map conceptually to NumericFunction and Variable classes.
*/

Expression x = Expressions.differentiate( a*a + 2*b + 3 ); to accomplish 
tasks amounting to differentiation directly on the btyecode for such a 
fragment of an equation. When this was run, Expressions.integrate would 
actually use BCEL to take the bytecode representing ( a*a + 2*b + 3 ) 
and transform it to bytecode representing ( 2*a + 2 ) which then would 
be what was evaluated when x.evaluate() is called.

-Mark

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

Mime
View raw message