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 Mon, 20 Oct 2003 16:30:53 GMT
Does look like MathBeans is already taken, interesting project with many 
parallel ideas, but private company and $$ oriented software:

http://www.numobjects.com/mathbean.html

Looks like others have encountered tradmark issues:

http://math.hws.edu/news/javagrant.html

-Mark

Mark R. Diggory wrote:

> Initially, I'd thought one would like to use Functor's BinaryFunction 
> and UnitaryFunction interfaces as the foundation of such Functional Math 
> objects.
> 
> http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/UnaryFunction.html

> 
> http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/BinaryFunction.html

> 
> 
> However, the whole concept of taking these as objects and plugging them 
> together in "runtime", or evaluating a group of them to accompish a task 
> like "Integration" becomes problematic when they are only connected 
> together during the "evaulate" method or during thier construction. See:
> 
> http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/core/composite/Or.html

> 
> http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/core/composite/And.html

> 
> 
> for some examples of this style.
> 
> I think one could just stick with the Function interface for the time 
> being, use bean properties to set the various sides of the function, and 
> provide a no arg constructor
> 
> http://jakarta.apache.org/commons/sandbox/functor/xref/org/apache/commons/functor/Function.html

> 
> 
> /* for summary Functions (Summation ...) */
> interface MultiMathBean extends Function {
> 
>     public void setArguments(Object[] objects);
> 
> }
> 
> /* for binary Functions ( +*/- ... ) */
> interface BinaryMathBean extends Function {
> 
>     public void setRightArgument(Object right);
> 
>     public void setLeftArgument(Object left);
> 
> }
> 
> /* for uniary functions (sin, cos, tan, ...) */
> interface UniaryMathBean extends Function {
> 
>     public void setArgument(Object object);
> 
> }
> 
> for example:
> 
> class Sin implements UniaryMathBean {
> 
>     Object object;
> 
>     public void setArgument(Object object){
>         this.object = object;
>     }
> 
>     public Object evaluate(){
>         if(object instanceof Number){
>             return Math.sin(((Number)object).doubleValue());
>         }else if ( object instanceof Function){
>             return Math.sin(
>                 ((Number)(
>                         (Function)object
>                     ).evaluate()
>                 ).doubleValue())
>         }else{
>             /* ... */
>         }
>     }
> }
> 
> 
> Sin sin = new Sin()
> sin.setArgument(new Double(1.0));
> Object o = sin.evaluate();
> 
> 
> Some may feel that this gets messy quickly, there alot of get/set going 
> on, but ultimately the goal isn't about making pretty or light java 
> code, it is more to provide runtime manipulation of the connections such 
> that you can easily manipulate the inter-relations of the bean objects 
> themselves.
> 
> Really the nature of this whole concept is to design a library of 
> "MathBeans" that can be easily manipulated in a BeanBox or other 
> application. So, there's a possible project name.
> 
> -Mark
> 
> 
> Mark R. Diggory wrote:
> 
>>
>>
>> Paul Libbrecht wrote:
>>
>>> 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.
>>>>
>>>>
>>>>
>>>> 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? 
>>
>>
>>
>> We're talking about taking existing class objects and optimizing into 
>> a new class hierarchy, then inserting them back into the classloader. 
>> So no, the classloader instantiation is still there. I suspect that 
>> other generic tools like gcj could be used to optimize that aspect 
>> further.
>>
>>> 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) ??
>>
>>
>>
>> Its less formal, BCEL lets you manipulate the bytecode, how one 
>> manipulates the bytecode is upto their own need.
>>
>>> 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.
>>>
>>
>> Thinking in Java
>>
>> http://www.codeguru.com/java/tij/tij0203.shtml
>>
>> This is probably the best resource to date that I've found about the 
>> cost of basic operations in java.
>>
>> It would be nice to provide some JUnit like classes to show these 
>> tests. I was hoping that with maven, we could possibly write a pluggin 
>> that does a sort of performance test, generating an xdoc of the 
>> results that can be used in the site generation. Ideally, one could 
>> write performance tests for any library and output the results to xdoc 
>> or any other format of interest.
>>
>>> There's a kind of related problem: what if I'm interested into a 
>>> manipulation of such a formula ? (e.g. integrate it).
>>>
>>
>> This is a "fun" idea.
>>
>>> Symbolic computation systems tend to have this in memory in a very 
>>> similar fashion to an XML-tree actually...
>>
>>
>>
>> Yes, I suspect your referring to the idea that one could manipulate 
>> instances of these objects to "plug" them into each other via things 
>> like get/set methods or bean properties. This would open up 
>> development of these "equations" on a number of "javabean oriented" 
>> visual tools.
>>
>>>
>>>>> 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 some thoughts about modularity are important, I've worked in a 
>> number of projects where the boundaries between dependencies tends to 
>> get out of control. I would suggest first working on an object model 
>> as a core, then possibly a separate package for 
>> serializing/deserializing things. I would almost suggest reviewing the 
>> commons components or other libraries to really determine if xml --> 
>> object --> xml is already available in a generic library of some sort.
>>
>>
>>>> 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...
>>>
>>
>> Yes, I tend to agree, the user works with these classes/objects, the 
>> framework deals with optimization capabilities transparent to the user.
>>
>>> 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.
>>
>>
>>
>> I really suggest we look over the functor component in the commons 
>> sandbox for a starting point, I suspect we will find a strong starting 
>> point here within functor to extend upon in this direction.
>>
>>
>>> - 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 ?
>>>
>>
>> I think we're really on the same page here. Could you post your 
>> examples of +*/- so we can get an idea of the design so far?
>>
>> -Mark
>>
> 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message