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

Attachment: archimedes.zip
Description: Zip compressed data

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to