octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #39566] Suspect interpft is wrong regarding tr


From: anonymous
Subject: [Octave-bug-tracker] [bug #39566] Suspect interpft is wrong regarding treatment of Nyquist frequency
Date: Thu, 25 Jul 2013 13:31:43 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.6.17-1.fc13 Firefox/3.6.17

URL:
  <http://savannah.gnu.org/bugs/?39566>

                 Summary: Suspect interpft is wrong regarding treatment of
Nyquist frequency
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Thu 25 Jul 2013 01:31:41 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Alain Cochard
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.6.4
        Operating System: GNU/Linux

    _______________________________________________________

Details:

As far as I understand, that is how interpft is working when the input
is a real array (I will speak only of a 1D array):

- take the discrete Fourier transform (DFT) of the array,

- zero-pad the transformed array, the zeroes being in the middle, so
  as to preserve the usual symmetry properties of the DFT,

- inverse DFT of the zero-padded array.

When the length, N, of the initial vector is even, there is only one
element of the DFTed array which corresponds to the Nyquist frequency
(both the negative and positive Nyquist values are real and equal).
When zero-padding, Octave chooses to keep its associated value in the
negative range.  To illustrate, simply take the DFT of the result, to
see the zero-padded array that Octave builds:

fft(  interpft([1 2 3 4], 6)  )'

   15.00000 -  0.00000i
   -3.00000 -  3.00000i
   -0.00000 -  0.00000i
    0.00000 -  0.00000i
   -3.00000 -  0.00000i   <<<< Nyquist
   -3.00000 +  3.00000i

Matlab chooses instead to take half of the value associated to the
Nyquist frequency and to put it both in the positive and the negative
range:

  15.0000          
  -3.0000 - 3.0000i
  -1.5000                 <<<< positive Nyquist
        0          
  -1.5000                 <<<< negative Nyquist
  -3.0000 + 3.0000i

I find Matlab choice more elegant since the zero-padded array has the
usual symmetry properties: zero frequency alone, negative frequencies
complex conjugate of positive frequencies.  However, the real parts of
the results of interpft are identical for Octave and Matlab, so I
would not really qualify this as a bug.

When the length, N, of the initial vector is odd, then there is a
positive and a negative Nyquist (complex conjugate of one another),
and there should be no choice for the zero-padded array.  Matlab
operates in the intuitive way:


fft(  interpft([1 2 3 4 5], 6)  )'

  18.0000          
  -3.0000 - 4.1291i
  -3.0000 - 0.9748i        <<<< positive Nyquist   
        0          
  -3.0000 + 0.9748i        <<<< negative Nyquist
  -3.0000 + 4.1291i


Octave, instead, puts the positive Nyquist in the negative range, next
to the negative Nyquist:


   18.00000 -  0.00000i
   -3.00000 -  4.12915i
   -0.00000 -  0.00000i
   -3.00000 -  0.97476i   <<<< positive Nyquist   
   -3.00000 +  0.97476i   <<<< negative Nyquist
   -3.00000 +  4.12915i


This choice is more crucial, because, in addition of the loosing of
the above mentioned symmetry, the result is different:

Matlab:


interpft([1 2 3 4 5], 6)'

    1.0000
    1.5266
    3.0894
    3.0000
    4.9106
    4.4734


Octave:


real(  interpft([1 2 3 4 5], 6)  )'

   1.0000
   1.9173
   2.1987
   4.0000
   4.3013
   4.5827


If this is a conscious choice of Octave, it seems to me that it should
be mentioned in the documentation.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]