commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <p...@activemath.org>
Subject Re: [math][functor] MathBeans was: (Re: [math] ... just one more reference...)
Date Tue, 21 Oct 2003 22:45:45 GMT
Mark R. Diggory wrote:
>> 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.

No!
Not without an evaluation context which can, for example, resolve 
current variables or, know the precision (that's important if one wants 
faithful operations, for example your Sqrt root is likely to loose 
precision on long-integers if I don't mistake, that should be checked!).

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

Presumably a flag interface, or... something like 
evaluate(EvaluatingContext xx) only...

>> So I would sort of revise Sqrt.java 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.

And it's ten times more complex in good systems.
As I said, the precision fuss could byte us... (and mathematicians tend 
to be precision freaks).

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

Well, if you look carefully into the code, I've avoided just about any 
new object allocation... If one uses a factory one could (after some 
implementation) re-use from a pool of MathObjectDouble (or such) thereby 
performing a zero-pollution computation (which, I believe, is the bone 
in terms of java performance tuning).
As far as I know, primitive typed local variables are in the stack so 
this would indeed make no pollution and we could hope to compute several 
hundreds or thousands of times per second...
It's just that "new xxx" is always allocating, the factory could 
allocate until we find the time to use a pool...

Paul


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