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?
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?
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 *'
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
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'?
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?