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 Wed, 22 Oct 2003 03:18:12 GMT

Paul Libbrecht wrote:
> 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!).

Yes, theres probibly many mistakes like that, this was only a rough 
draft of an idea.

I understand you logic behind maintaining a Context with info concerning 
precision. It is sensible.

If pooling is used like you've stated below, yes we'ed need another 
mutable data wrappper for the values being passed between evaulate 
methods. These could still be Numbers (although thats not saying much, 
again its just several primitiveValue()) wrappers

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

precision is always going to be an important issue.

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

I've use commons pool before. The important thing to point out is that 
you need to always return your objects to pool after your done with 
them. It may be tricky to maintain if things like MathObjects can get 
handed outside of the EvaluatingContext in any way.

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message