[Octave-bug-tracker] [bug #43673] fft() gives incorrect result for 3-dim array with singleton 3rd dimension

[count]

Follow-up Comment #11, bug #43673 (project octave):

Thank you for your reply! I just have no experience of contributing code to a
project, and don't know how the whole process flow go. (Should I join the
mailing list  address@hidden)

The dimensions resized (as you pointed out) because I want to deal with these
cases (and the expected results):


> a = [1 2;3 4];
> fftlen=0; fft( a, fftlen, 3)
ans = [](2x2x0)
> fftlen=1; fft( a, fftlen, 3)
ans =

   1   2
   3   4

> fftlen=2; fft( a, fftlen, 3)
ans =

ans(:,:,1) =

   1   2
   3   4

ans(:,:,2) =

   1   2
   3   4



Note the "a" in the code could come from "a=b(2,2,1:1)", so this 2-dims to
3-dims transform is not weird.

So, except for fftlen==1, I have to resize the dimensions, since the result
has dimensions like that.

Of course, these are trival cases of Fourier Transform. Here I choose a way
that fix the bug with least code, instead of treat these cases specially. Not
100% sure if this is the right thing to do.
Oh, Maybe I shoud mension these concerns when providing the patch.


For dNDarray.cc, we don't need to worry the resize of dimensions because there
is no the "N" parameter (fft length) there


-- Loadable Function:  fft (X, N, DIM)
v.s
ComplexNDArray
NDArray::fourier (int dim) const


So for the case of "dim >= dims.length ()", the dNDarray.cc code is always
doing "fft (X, 1, DIM)", which is the special case mensioned above
(fftlen==1). Return the result immediately is clearly more understandable than
fix the index range logic in NDArray::fourier().



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43673>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/