bugGNU Octave - Bugs: bug #45932, ifft(fft(x)) is not real for x real


bug #45932: ifft(fft(x)) is not real for x real

Submitted by:  Marco Caliari <caliari>
Submitted on:  Fri 11 Sep 2015 02:42:12 PM UTC  
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Inaccurate Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Thu 25 Jan 2018 07:43:10 AM UTC, comment #3:

I do not think that removing the imag part if small is safe. The problem in fact is the choice of K. But, there is no heuristic. In xhat of the original example, xhat(1+i) is exactly equal to conj(xhat(n+1-i)). This should be the check and the only case in which to apply the zeroing of the imaginary part.

As a second step, I think to remember that there is a proper function in FFTW to manage this case, which does not compute at all the imaginary part, but Octave does not use it (at least, when I submitted the report).

Marco Caliari <caliari>
Project Member
Wed 24 Jan 2018 06:11:12 PM UTC, comment #2:

We can check if max(abs(imag()) is smaller then K*eps, and zero imag() if the answer is yes.
But how can we set K? Is it depend on vector/matrix size?

Avinoam Kalma <avinoam>
Project Member
Sat 12 Sep 2015 12:40:57 AM UTC, comment #1:

No, there is no detection that the input is conjugate symmetric. If the (ifft) input array is complex, then a complex-to-complex inverse FFT is done and the output is complex.

It might make sense to add some heuristics to detect some of the symmetric special cases, if not to choose a different function then to at least clean up the round-off errors in the output.

Also note the roundoff error in double vs single:

Mike Miller <mtmiller>
Project Administrator
Fri 11 Sep 2015 02:42:12 PM UTC, original submission:

If x is a real vector, say


has the property xhat(1+i)=conj(xhat(n+1-i)). In this, it seems to me that Octave uses the rfftw transform of FFTW. But if we now compute

we get a complex vector with spurious imaginary parts. For comparison, Matlab gives a real vector. Would'n it possibile to use an (inverse) rfftw transform of FFTW? Or, alternatively, check the input and return only the real part? Notice that this report is related to #43742.


Marco Caliari <caliari>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by caliari (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 12 Sep 2015 12:40:57 AM UTCmtmillerStatusNone=>Confirmed

    Back to the top

    Powered by Savane 3.1-cleanup1