<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic One more note: Matlab uses in Intel® Integrated Performance Primitives</title>
    <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963803#M19901</link>
    <description>&lt;P&gt;One more note: Matlab uses IPP FFT internaly for performance - so results must be the same.&lt;/P&gt;
&lt;P&gt;Regards, Igor.&lt;/P&gt;</description>
    <pubDate>Mon, 28 Oct 2013 14:48:19 GMT</pubDate>
    <dc:creator>Igor_A_Intel</dc:creator>
    <dc:date>2013-10-28T14:48:19Z</dc:date>
    <item>
      <title>Insufficient FFT output accuracy</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963799#M19897</link>
      <description>&lt;P&gt;Hello!&lt;/P&gt;
&lt;P&gt;I'm calculating FFT of a complex signal using ippsFFTFwd_CToC_32fc function with order=10 (1024) and IPP_FFT_DIV_FWD_BY_N flag in Init. After applying my custom window (based on WinBlackmanStd) to the input data, one element of the output data in frequency domain gets exactly zero value (0, 0). As Matlab says, that element is the smallest element in the output array, its absolute value is near others':&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;BR /&gt;Sp(30:35)&lt;BR /&gt;ans =&lt;BR /&gt;&amp;nbsp; 1.0e-005 *&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0754&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1696&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0231&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1748&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.4586&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6651&lt;BR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;/P&gt;
&lt;P&gt;This matlab output shows elements surrounding the problem 32nd element, which becomes zero in IPP's FFT output. The dynamic range of samples in frequency domain is from 0.8e+2 to 0.2e-6. I tried to use ippAlgHintAccurate flag, but it had no effect. Is seems like internal IPP's algorithms have insufficient accuracy while computing FFT.&lt;/P&gt;
&lt;P&gt;If it is necessary, I can provide input and window samples.&lt;/P&gt;
&lt;P&gt;Best Regards,&lt;BR /&gt;Aleksey&lt;/P&gt;</description>
      <pubDate>Thu, 24 Oct 2013 11:21:29 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963799#M19897</guid>
      <dc:creator>AlekseyS</dc:creator>
      <dc:date>2013-10-24T11:21:29Z</dc:date>
    </item>
    <item>
      <title>The IPP function is 32 bit</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963800#M19898</link>
      <description>&lt;P&gt;The IPP function is 32 bit float = "Single"; this having approx. 6.5 significant digits, which could be the problem.&lt;/P&gt;
&lt;P&gt;Did you try to run your code using ippsFFTFwd_CToC_64fc? (if it exists, I didn't check).&lt;BR /&gt;With it, you could see where your digits are truncated.&lt;/P&gt;</description>
      <pubDate>Thu, 24 Oct 2013 16:11:45 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963800#M19898</guid>
      <dc:creator>Thomas_Jensen1</dc:creator>
      <dc:date>2013-10-24T16:11:45Z</dc:date>
    </item>
    <item>
      <title>yes, exactly - pls try the</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963801#M19899</link>
      <description>&lt;P&gt;yes, exactly - pls try the 64fc version of this function.&lt;/P&gt;</description>
      <pubDate>Fri, 25 Oct 2013 05:22:38 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963801#M19899</guid>
      <dc:creator>Gennady_F_Intel</dc:creator>
      <dc:date>2013-10-25T05:22:38Z</dc:date>
    </item>
    <item>
      <title>Thanks a lot! Yes, 64fc</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963802#M19900</link>
      <description>&lt;P&gt;Thanks a lot! Yes, 64fc version of FFT works properly. I overestimated float 32-bit function accuracy for my input signal with large dynamic range.&lt;/P&gt;</description>
      <pubDate>Fri, 25 Oct 2013 07:48:46 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963802#M19900</guid>
      <dc:creator>AlekseyS</dc:creator>
      <dc:date>2013-10-25T07:48:46Z</dc:date>
    </item>
    <item>
      <title>One more note: Matlab uses</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963803#M19901</link>
      <description>&lt;P&gt;One more note: Matlab uses IPP FFT internaly for performance - so results must be the same.&lt;/P&gt;
&lt;P&gt;Regards, Igor.&lt;/P&gt;</description>
      <pubDate>Mon, 28 Oct 2013 14:48:19 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/Insufficient-FFT-output-accuracy/m-p/963803#M19901</guid>
      <dc:creator>Igor_A_Intel</dc:creator>
      <dc:date>2013-10-28T14:48:19Z</dc:date>
    </item>
  </channel>
</rss>

