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:I like the EvaluatingContext idea, good for parameterization etc. Very Jelly like too.
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
