Hi.
> [...]
> >> >
> >> > 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.:
---CUT---
public double[][] transform(double[][] dataRI) { /* ... */ }
---CUT---
And you can pass your data to the CM code in a matter of two array reference
assignments.
> [...]
Best,
Gilles
[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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
