commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math][functor] More Design Concerns
Date Tue, 01 Jul 2003 22:19:38 GMT
Al Chou wrote:

>--- "J.Pietschmann" <> wrote:
>> 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.
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"

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 Diggory
Software Developer
Harvard MIT Data Center

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

View raw message