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.
Indeed, not purely server... but, you know, servers are doing more and more. The ability to input a formula, have a parser to, and provide any kind of result is sort of a server job (think, for example, of WebMathematica).
But the server-bias is kind of loosing it's power at Jakarta. What about log-factor 5 (a part of log4j), what about jelly-swing and jelly-swt?
To my taste, Apache foundation is the home of Apache License, along with a large tradition that has been propelled by server-orientation. I would believe it would make sense to make components somewhere at Apache under some project or even on Jakarta....
[...]
the technologies XML and Object should stay very separate. Much in the way that Model and View stay separated in MVC.
Definitely agreeing. Also meaning that what we're doing is pretty much model whereas OpenMath/MathML/put-your-syntax-here is just parsing (slightly outside model)...
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.projects (as you can see).
Archimedes is nice but it might very well be protected. I should find some other founding mathematicians around... we could even take a living mathematician!
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.
Mmmh, I did not know of this requirement and it's not the case of Jelly.
The latter is quite a rich one with many sub-project (so many that actually very few people have managed to compile it all because one needs, in its repository, a copy of many non-downloadable jars).
Maybe we should go to the incubator and attempt to set "subprojects" or "applications" of the library up there.
Not sure to see what this means... I would really put them in the same source-tree and produce separate artifacts.
It might make sense, also, to have actually artifacts from even the core. Examples include implementations of algorithms and maybe even exotic collection of functions (e.g. the Gamas and such in probability).
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.
Optimization seems to haunt you... we need test-cases before, or ?
At least I know that optimization for straight-evaluation would indeed make good use of BCEL but I doubt it makes sense for other uses where the only good-optimization can be done on the knowledge of the nature of objects being treated (e.g. apply the right process to get a primitive or to solve an ODE).
2.) BCEL could be used to manipulate the bytecode for an Expressions Object Hierarchy to accomplish tasks like Integration/Differentiation.
But the API should be readable enough not to need BCEL for that!!
(remember, one of the easiest way to do it, at least on a server, would be to use external symbolic systems).
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.
OK, I see BCEL of use to be able to read from the bytecode the expression (properly located somewhere in a method in a java-class) and understand a formula out of that.
That would be a parser to our data-structure from java expressions.
(BeanShell 2 can do this at the source-level I think).
The next usage would be to sort of modify this to change a class or produce a new class, is that right ?
Why not... well... after all... maybe when working on objects one wants to obtain properties about (e.g. meta-reasoning about primitive computing agents, maybe ?).
Will now have a look to archimedes.zip...
Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
