ippsDivCRev_32f_I bug when divide by zero occurs?

[jeffc111]

I ran into what I think is a problem with the inplace variant of DivCRev. I haven't tested other variants...

When an element of the source/destination vector is zero on input, the output contains #INF for that element, but the 4th element following that value is also #INF.

Is that expected behavior? I can imagine that the return value (which is, appropriately,ippsStsDivByZeroErr) might mean that the result is invalid, and that this behavior may have been chosen for performance reasons. However, it's not what I expected, and is not clearly documented.

The documentation is incorrect with respect to the return value - "Indicates an error when val is equal to 0", except it's not val that's zero, it's an element of the input vector.

Here is the sample code I'm using. I'm running x64, and have tried release and debug.

int _tmain(int argc, _TCHAR* argv[])

{

Ipp32f* values = ippsMalloc_32f(100);

ippsSet_32f(1, values, 100);

values[10] = 0;

IppStatus result = ippsDivCRev_32f_I(2, values, 100);

return 0;

}

int _tmain(int argc, _TCHAR* argv[]){ Ipp32f* values = ippsMalloc_32f(100); ippsSet_32f(1, values, 100);
values[10] = 0;
IppStatus result = ippsDivCRev_32f_I(2, values, 100);

return 0;}

[jeffc111]

I tested the out-of-place version, and it has completely different behavior - it returns 0.0f for the input element that is zero, and it does not exhibit the 4th element anomaly.

[Joseph_S_Intel]

I am submitting a bug for the documentation, and it does seem strange that the 4 element after the element with a zero value is changed; so I am investigating that.

I get the same behavior for the out-of-place version when I tried this:

int _tmain(int argc, _TCHAR* argv[])

{

Ipp32f* values = ippsMalloc_32f(100);

Ipp32f* dstvalues = ippsMalloc_32f(100);

ippsSet_32f(1, values, 100);

values[10] = 0;

IppStatus result = ippsDivCRev_32f(values, 2, dstvalues, 100);

IppStatus inpresult = ippsDivCRev_32f_I(2, values, 100);

return 0;

}

[Ivan_Z_Intel]

There is the bug in this function.
It will be fixed in next version.
Thanks very much!