Ok, here's an implementation with an EvaluationContext, let me know what you think. Its almost java.lang.Number free, I cut corners and extended Number in the DefaultContext.DefaultValue InnerClass.

It doesn't depend on Functor because the Evaluation class doesn't really match up to that API now. :-( Oh, Well.

-Mark

Paul Libbrecht wrote:
Mark R. Diggory wrote:

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


Note that this was not the context in the sense of a "configuration" or such (e.g. that would say which algorithm should be used to do this or that)... It was more the description of an evaluation-process.

A more funky EvaluatingContext would be the computation of types or return types....

precision is always going to be an important issue.


That can all make it hard...

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.


At worst, that's done in the finalize method...
Only routines that will return the object to pool will be efficient, that's about enough for a rationale.
Commons-pools is probably a good choice...

Still not wanting to have this in commons-math ?
Anything about this policy of having a single artifact per commons sub-project ?

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

Attachment: archimedes.zip
Description: Zip compressed data

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to