[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #43673] fft() gives incorrect result for 3-dim
From: |
count |
Subject: |
[Octave-bug-tracker] [bug #43673] fft() gives incorrect result for 3-dim array with singleton 3rd dimension |
Date: |
Sun, 14 Dec 2014 08:04:14 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 |
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/