Intel® Integrated Performance Primitives
Community support and discussions relating to developing high-performance vision, signal, security, and storage applications.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
6594 Discussions

ippsPowerSpectr_32fc producing wrong results

Intel_C_Intel
Employee
214 Views

We have an application that uses ippsPowerSpectr_32fc many (many) times (along with other IPP functions). Recently we modified our program to be more efficient (by callingthis functionwith a smaller vector of data). However we wanted to test the change, so we continued to call the function with both the original vector and the sub-set to ensure that theexpected results are achieved.

After the app is running for a while, we started getting differences between the full-set and sub-set results. Later, while trying to understand the issue, we started using our own ippsPowerSpectr function in addition to the IPP one and compared the output. We noticed small differences (< 5e-8) in the output of the IPP function compared to our hand written one. Even though they are small, they do make a difference in some cases, and we would like to resolve this.

These differences only show up when our app has been running for a while (and the IPP library has entered some 'state' - repeated calls to both the IPP function and our own continue to show the same differences - however, if I write the associated data to a disk file, read it into a stand-alone app, then call the IPP and our functions again, there are no differences - so again, there seems to be some kind of state information that is affecting the result of the ippsPowerSpectr call).

So perhaps this is best answered by Intel, but all comments are welcom. Are there any variables/parameters that affect the result of ippsPowerSpectr? Is there a way set/reset them?

0 Kudos
9 Replies
Vladimir_Dudnik
Employee
214 Views

Hello,

it would be nice if you can specify what version of IPP do you use, what is your linkag model, what is your target system and operating system where you run your application.

It also looks like you have complex enough application, so after IPP cal you probably have some additional operations on the data processed by IPP, so it is possible to influence on the results.

Strange that you saw difference smaller than can be represented in Ipp32f data type. Do you use convertion to double precision after IPP processing?

Regards,
Vladimir

Intel_C_Intel
Employee
214 Views

I'm using Windows IPP 5.2. This problem occurs (reliably in at least oneinput data set after ~5 minutes of processing) if I link statically or dynamically.

We are not doing any operations after the IPP function. We are not converting the data from float to double, and the error is approximate - representing a ratio of the difference between the value computed manually and the value produced by the IPP.

Basically I call the IPP function with the input vector and save the result, then I call the manual function with the input and save that result. If I then perform a binary comparision of the output they are different. Then the code moves through the output vectors to determine which specific vector elements are different. What we see is at least one element in the vector produced by the IPP is off by a small amount.

A can do this as many times as I want (using the same input vector and seeing the same difference) once the IPP is in this state. But if I perform a binary write of the associated data to disk, perform a binary load of the data in a stand-alone app, then call the IPP function and our hand written one,I get no binary differences.

FYI, the 'manual' function is doing this:

*pMtemp = (pCtemp->re * pCtemp->re) + (pCtemp->im * pCtemp->im);

where pMtemp is a 'float *', and pCtempis a 'Ipp32fc *'

astrasel
Beginner
214 Views

Here is some additional data. If I call the ippsPowerSpectr_32fc IPP function on an 8 element array of complex data (not shown), I get the following:

0.83778727 0.86766392 0.73586142 0.76573807 4.1397133 4.0079107 3.9059849 4.1695900
(in binary: 3f56793a 3f5e1f39 3f3c616a 3f440769 40847888 408040ce 4079fba8 40856d48)

If I compute the result using my 'manual' calculation, I get this:

0.83778733 0.86766392 0.73586148 0.76573807 4.1397133 4.0079107 3.9059849 4.1695900
(in binary: 3f56793b 3f5e1f39 3f3c616b 3f440769 40847888 408040ce 4079fba8 40856d48)

Note small differences

ILevi1
Valued Contributor I
214 Views

Can you test on another computer to eliminate hardware problems as a possible source of error?

Vladimir_Dudnik
Employee
214 Views

it would be nice if you can provide a simple test case to reproduce that issue. We were not able to reproduice it at our internal testing

Regards,
Vladimir

astrasel
Beginner
214 Views
I was able to reproduce this on multiple computers, and created stand-alone app with results. All was submitted as an issue to Intel
Vladimir_Dudnik
Employee
214 Views

Thank you for your effort on this,it will significantly help us in investigation of that issue

Vladimir

astrasel
Beginner
214 Views

Well Intel has decided this is not an error, even though all the posts on this thread seem to believe it to be so, as well as myself.

How can anyone look at a result that is produced by C code against a result from the IPP, see that they are not equal and not consider this an 'error'?

Vladimir_Dudnik
Employee
214 Views

Well, what is the problem? Is that the fact that result of this function differs inseventh digit after decimal point for single precision floating point data type?

Vladimir

Reply