--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:I'm thinking there are still different cases we need to break down further. Object Creation needs review on both the "input parameters" and the "output parameters"
[EMAIL PROTECTED] wrote:
I would steer away for primative as much as possible.Keep in mind that excessive object creation can and usually is
a significant performance drain, both because it is slow in itself
despite all kinds of optimization as well as causing more GC.
I think we should consider what the typical use cases will be for this library. Of course we could turn out to be wrong about that, but given that it's not supposed to be a heavy-duty numerics library, perhaps a more purely-OO design is not necessarily a bad thing. For instance, if we find that the library is mostly used to calculate the minimum, maximum, and average of a set of numbers for a report, and that report is only run once a month, then the efficiency of primitives vs. objects isn't that important.
Of course we should not paint ourselves into a corner regarding the design. If many users start using the library for intensive numerical tasks, it would be good if the library's design was flexible enough to accommodate any needed efficiency improvements.
One thing that I am curious about is the design of COLT, which claims to have very good performance.
Al
for input parameters having method signatures with both primitive and Object parameters gives us both flexibility and opportunity for efficient addition/calculation of values of various types.
interface SomeCollection {
public void addValue(Number value)
public void addValue(double value)
public void addValue(double[] value)
}interface SomeStatistic {
public double evaluate(SomeCollection values)
public double evaluate(double[] values)
}The big questions are how often is it really important to have an "Object return value" returned in a math package and, if this happens "alot" are there alternatives that can keep such returns efficient. I.e. if you provide a Double wrapper object return, there can possibly be other primitive return methods as well.
interface UnivariateStatistic extends Function{
public double evaluateToDouble(double[] values)
public Object evaluate(double[] values)
}And then optimize accordingly
class Sum implements UnivariateStatistic {
public Object evaluateToDouble(double[] values){
double accum = 0.0;
for (int i = 0; i < values.length; i++) {
accum += values[i];
}
return accum;
}public Object evaluate(double[] values){
return new Double(evaluateToDouble(values));
}
}
As long as the "User Interfaces" are functioning on primitives, it would appear an important design requirement to me. Remember that the Functor package objectifies Functions, Predicates and Procedures. As long as Object evaluate(Object obj); returns an appropriate object, its not out of the realm of possibility to provide an extension of these interfaces to work with primitive oriented content. The math project is coming from the standpoint of already implementing a majority of its functionality based on primitive returns and parameters, so its an important consideration to ponder.
-Mark
-- 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]
