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

[count]

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

The function NDArray::fourier is still using uninitialized memory in the
example case
> fft( zeros(2,2,2), 1, 3 )

zeros(2,2,2) is been copied(during resize) and dimension squeezed to
zeros(2,2) (liboctave/array/Array.cc:1033 Array<T>::resize).

Then in liboctave/array/dNDArray.cc (and probably also exist in other
xxNDArray.cc) the check in line 104
  if (dim > dv.length () || dim < 0)
fail to recognize this case (dim==2, dv.length ()==2). I guess the author want
something like
  if (dim >= dv.length () || dim < 0)

Then the access (line 108)
  octave_idx_type n = dv(dim);
conceptually should be an out of bound access. In my debug, it returns n = 32
(totally wrong).

As a consequence, nloop = 0, so the main loop in line 123
  for (octave_idx_type k = 0; k < nloop; k++)
does not even run.

This finally lead to the space allocate in line 119,120
  ComplexNDArray retval (dv);
  Complex *out (retval.fortran_vec ());
been returned without initialization.


The inverse Fourier interface NDArray::ifourier returns a correct final result
because its space allocation is (line 150)
  ComplexNDArray retval (*this);
So it is already been initialized (despite of nloop==0).


BTW: I see here a potential speed improvement of NDArray::ifourier, it is
using in-place FFT, which is slow than the "out-place" FFT in NDArray::fourier
(maybe by a factor of 2).

    _______________________________________________________

Reply to this item at:

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

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