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 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.
You mention some thoughts about object factories for MathObjects, can you outline some of your ideas with this?
Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
