commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Major speed improvement to 1D FFT (MATH-732)
Date Tue, 07 Feb 2012 12:57:40 GMT

> [...]
> >> >
> >> > I remember we recently had this conversation on the ML: one of Gilles
> >> > or Luc argued that for very low-level algorithms, it didn't really
> >> > matter if the parameters were passed as "very crude" objects, since it
> >> > was most likely that the user would have to write an adapter to its
> >> > own data format. So I would suggest we give up Complex[] altogether in
> >> > the interface of FFT, and replace it with double[] arrays, with the
> >> > following layout :
> >> > data[2 * i] = real part
> >> > data[2 * i + 1] = imaginary part.
> >> >
> >> > What do you think?
> >>
> >> I agree with this view (it may be me who expressed this). A double array
> >> as an interface for our library seems good to me.
> >
> > I'm wary of this sort of "optimization" (as it decreases the code clarity).
> >
> > -1 until it has been proven that it brings a _significant_ performance
> >   improvement.
> > At the moment, I would of course keep the internal switch to arrays of
> > primitives but also the API that takes and returns "Complex[]" objects.
> >
> Well, in fact this change was not really thought of as an
> optimization. It seemed to me that this data layout was more
> natural... But it's probably because I'm used to it. I should mention
> that having to create an array of Complex is the very reason why I do
> not use the transform package for my own calcs. Indeed, my data comes
> in double[] arrays. So I would have to turn this data into Complex[],
> which would internally be converted back to double[] arrays...

Wherever it makes sense from a user perspective[1], nobody prevents you from
adding new methods to the API, e.g.:
public double[][] transform(double[][] dataRI) { /* ... */ }
And you can pass your data to the CM code in a matter of two array reference

> [...]


[1] As long as the code remains self-documenting: I'd prefer to avoid, as
    much as possible, "out-of-band" conventions, like striding over a
    one-dimensional array to get different kinds of data (cf. real vs
    imaginary part: Another "natural" convention could be that the first
    half of the array contains all the real parts and the second half all
    the imaginary parts).
    Of course the "double[][]" also poses the question of the data ordering,
    but I have the impression that it is more flexible (and it could even be
    faster ;-).

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

View raw message