commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Issues 650, 675, 676
Date Fri, 30 Sep 2011 22:03:29 GMT
> >
> > Referring to:
> >
> >
> >
> >
> > In the absence of additional comments I'm proposing to resolve those issues.
> > Please let me know whether there are pending objections to my suggested
> > solutions.
> Regarding MATH-650 (FastMath)
> If the proposal is to use resources instead of static arrays, then I
> disagree, because resources are significantly slower than static
> arrays.
> I am opposed to storing the arrays in package protected classes,
> because that exposes the data unnecessarily.
> However, if you really cannot agree to the including the static arrays
> within the FastMath class itself, then I suggest using separate
> classes with private arrays and package-protected getters.

It has been shown that literal arrays are faster than resources in one
micro-benchmark instance: Namely, an application that consists of a single
function call. We still wait for a real use-case where the difference will
significantly matter.

I'm sorry to observe that in a serious project like this one, nobody is
willing to acknowledge that there should be a reasonably argued (and
constant) policy about changing code.
Indeed, I cannot agree on having changed "FastMath" in that way; at least,
the approach of storing the humongous arrays in other files/classes should
have been taken as a first step towards solving the reported problem.

Independently, I think that the right way to load this kind of data is
indeed via the "resources" functionality. If this is so, one should rather
ask whether the loading time can be improved. In fact, I wonder why loading
resources should be "so much" slower than arrays (18 ms vs 6 ms).

Hence, if there is still no consensus on that issue, you are welcome to
create the helper classes as you suggest (which, IIRC, is what I had also
suggested from the outset).
That way, both alternatives will be on an equal footing for further testing.


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

View raw message