commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math][functor] MathBeans was: (Re: [math] ... just one more reference...)
Date Tue, 21 Oct 2003 22:37:19 GMT

Paul Libbrecht wrote:
> Mark R. Diggory wrote:
>> 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.
> Mark,
> In there the functions and operators take directly number as 
> arguments... why ? 

My thoughts were the following, Step back and look at NumericalFunction, 
it extends Number as well. This means that Constants can just be added 
as the various java.lang.Number implementations. Arguments for the 
operands can be any java.lang.Number or any NumericalFunction. This 
allows us not to have to implement our own custom Constant wrappers. All 
the java.lang.Number class requires/enforcees are the methods to get to 
each primitive type (intValue, doubleValue, ...) I suspect we would be 
requiring these sort of methods eventually anyways.

> Why don't they take sub-expressions ? (it should be 
> something like setOperand(MathObject ob))... wether it can be computable 
> or not could be checked at set time but they should, I believe, only be 
> checked at run-time...

What would a MathObject look like in your book?
> Also, you differentiate between Operators and Functions... I don't 
> really see why... the difference is mostly notational.
> I also think Multiply and Adds should be multi-argument, not just binary...

Just because I like to categorize. Operators were focused primarily on 
+/-*%^ operands defined in java, while functions ... should be obvious. 
Not that any of this needs to stay this way.

> So I would sort of revise into:
>     private MathObject argument;
>     public void setParent(MathObject parent)
>     public MathObject getParent...
>     public void setOperand(MathObject argument) {
>         this.argument = argument;
>     }
>     public MathObject evaluate(EvaluatingContext context)
>           throws EvaluationException {
>         MathObject argEvaluated = argument.evaluate(context);
>         if ( EvaluatingContext instanceof DoubleEvaluating ) {
>             double argAsDouble =
>                 ((DoubleEvaluating)context).getAsDouble(argEvaluated);
>             return new Double(Math.sqrt(argAsDouble));
>             // or (to plug re-using object factories)
>             // return context.makeDoubleResult( Math.sqrt(argAsDouble));
>         }
>     // follow with other types...
>     }
> // call to evaluate could also be specialized beforehand
> (i.e. Sqrt could be a type of DoubleNumericFunction, having 
> evaluateDouble and the context would only call evaluateDouble)
> How does it taste ?

I like the EvaluatingContext idea, good for parameterization etc. Very 
Jelly like too.

I was trying to maintain the same casting rules in my evaluations as 
defined by java, this way if the type passed through the evaluation of 
the operands was "Integer" the proper java.lang.Number intValue() value 
method would be called to retrieve the appropriate type, although this 
is probibly more complex than an implementer would like.

You mention some thoughts about object factories for MathObjects, can 
you outline some of your ideas with this?

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

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message