"fft" function : random results with N > signal length

I’m encountering strange issues on octave, with fft function. The problem occurs only on my computer, I tried several other, and everything seem good.

When I call “fft” function ( fft (X, N) ) with N superior to X length, the result seems to be random.
(reminder from help: If N is larger than the dimension along which the FFT is calculated, then X is resized and padded with zeros.)

My script for example:

f=fft(val, l*2);

(the 4 plots below are 4 different execution of the script above)

I tried different octave version (repository debian-testing 5.2, snap version 5.2 & 6.1 ), the problem is still here.
On octave 4 (debian-stable) it was ok.

Could the problem come from signal package instead of octave ?
Maybe some low level driver problem ? (I don’t know if octave use some hardware acceleration for calculation or something like this…).

Or maybe I am the problem, with a wrong usage, but I don’t know where ?

Thank you !

Your code looks correct to me.
I also don’t know what could cause such a behavior.

Could you please try the following to check which values are used for the padding?

f=fft(val, l*2);
g = ifft(f);

I’m not certain if this is the same code path. But could you also please check what you see for the following commands on the affected system?

clear A
A(4) = 1;

It should be [0 0 0 1].

I placed these commands in a file tst_fft.m which I have uploaded .tst_fft.m (73 Bytes)
I can then run tst_fft repeatedly. For me, the plot is always exactly the same without variation. It looks like this

I get the same as Rik.

Hello ,

f=fft(val, l*2);
g = ifft(f);

This give me random results too (see plots).

clear A
A(4) = 1;

This give me [0 0 0 1]

I get the same as Rik.

Yes, and that’s what I was expecting…

Don’t know if it can help someone, but here is my package list:

Package Name | Version | Installation directory
control | 3.2.0 | /home/rov/octave/control-3.2.0
signal | 1.4.1 | /home/rov/octave/signal-1.4.1

Thank you

That doesn’t look anything like the original signal at all…

I’m wondering where this could go wrong. Essentially, we are resizing the input to match N with the resize member function of the NDArray class (or similar classes for float or complex input):
libinterp/corefcn/fft.cc (line 142): nda.resize (dims, 0.0);
That essentially calls std::fill_n in the function Array<double>::resize2 to fill the new elements with 0.0 (in liboctave/array/Array.cc (line 969)).
The result of that operation is passed over to the fftw library essentially:
liboctave/array/dNDArray.cc (line 100)

All of this doesn’t look very fragile at first sight.
Does the affected system have some kind of exotic hardware (where e.g. our assumptions about memory layout could be wrong)?

This is just weird, and if it were a widespread problem would be noticed immediately. The fact that you have tried different versions of Octave suggests it is not the software, although it is not definitive.

Some debugging questions

  1. What hardware are you using?

  2. Verify that no user initialization file is changing settings

Start octave with -f flag which prevents loading initializations.

sh> octave -f
octave:1> tst_fft
  1. Verify signal package is not the problem
octave -f
octave:1> pkg unload signal
octave:2> tst_fft
  1. Do you have the libfftw3 installed?

This library is what Octave typically uses for computing FFTs. In prior versions if the library was not present Octave would fall pack to FFTPACK (Fortran code).

  1. Do you have NVIDIA HW which might be stealing library calls?

It might be that NVIDIA’s libcufftw is present and trying to run calls to libfftw on a graphics accelerator without getting everything right.

Indeed, maybe some package on my system is causing that. I think a fresh debian install could fix the problem, but I want to understand what happen (and I don’t really have time for that)

Standart computer and never modified:

  • Hardware
    Dell precision (3620) with intel i7-6700, with integrated gpu.
  • software:
    Linux rov-pc 5.9.0-5-amd64 #1 SMP Debian 5.9.15-1 (2020-12-17) x86_64 GNU/Linux

Same result with "-f"

Same result (thought fft was from signal package, but it seem to be from octave core)

Yes (3.3.8-2)

No, only integrated gpu.

If it come from some octave dependencies, I should find some software which use the same dependencies to check if they are working great

You said you tried building your own version of Octave. Could you run configure and capture the results in a log file and upload them?

Beyond that, I agree that I don’t know how much further we can go in debugging this. It seems to be very system-specific.

I didn’t do it yet, but I’ll try when I will find some time
Thank you for your help,