ippsMax/Min_64f producing odd values when NaN is included

[Ben_Young]

I have a vector that looks like this:

1, 1.5, 2.0, Inf, -Inf, NaN

I'd expect ippsMax_64f and ippsMin_64f to both return NaN but Max returns 2.0 (!) and Min returns -Inf (which at least makes sense)

Is there a document that describes the NaN handling if the IPP library? Either way the above results look wrong.

Also, is there a convienent way of stripping NaNs from a vector? I'm using ippsThreshold_LTValGTVal_64f(a, vout, n, 0, 0, 0, 1); to simulate v > 0, but because of the way it works it handles NaNs differently from the "naive" implementation.

[PaulF_IntelCorp]

Hello Ben,

Sounds like a bug, I'll file a bug request.

Can you tell me which version of the library you're using?

Paul

[Ivan_Z_Intel]

Hello Paul, Ben!

The result of running of functions ippsMax_64f, ippsMin_64f is undefined if there is NaN element in vector.

There isnt any ipp-function for removing NaN-element from vector.

However below you can see the example of function (checkNAN) substituting real value for NaN.

void checkNAN( double* vec, double value, int len )
{

__int64* v;

__int64 t;

int i;

v = (__int64 *)vec;

for ( i = 0; i < len; i++ ) {

t = v & 0x7fffffffffffffffL;

if ( t > 0x7ff0000000000000L ) vec = value;

}

}

int main( void )

{

double vec[6];

__int64 *veci64;

int i;

veci64 = (__int64)vec;

vec[0] = 1.0;

vec[1] = 1.5;

vec[2] = 2.0;

veci64[3] = 0x7ff0000000000000L;

veci64[4] = 0xfff0000000000000L;

veci64[5] = 0x7ff7ffffffffffffL;

printf("\n Before:\n");

for ( i = 0; i < 6; i++ ) {

printf("%f ",vec);

}

checkNAN( vec, 0.0, 6);

printf("\n After: \n");

for ( i = 0; i < 6; i++ ) {

printf("%f ",vec);

}

return 0;

}

Before:

1.000000 1.500000 2.000000 1.#INF00 -1.#INF00 1.#SNAN0

After:

1.000000 1.500000 2.000000 1.#INF00 -1.#INF00 0.000000

[Ben_Young]

Thanks you very much

Its 7.0 Update 2.

[Ben_Young]

Thanks, I'll look into doing that, but can you explain why it's undefined? Is there a doc that states the NaN policy of each function, as we rely on handling NaNs in our app, so this would make it hard to use IPP in all places

[PaulF_IntelCorp]

Hello Ben,

There are some appendices in the documentation that describe how some of the IPP functions handle NaN and other special numbers, however, the functions you are inquiring about are not described in those appendices. I've asked that the documentation be updated and/or the functions be amended to include more clarity regarding this kind of situation.

The appendices I am referring to are here:

http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/ippxe/ipp_manual_lnx/hh_goto.htm#IPPS/ipps_appendices/ipps_appA_Intro.htm

http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/ippxe/ipp_manual_lnx/hh_goto.htm#IPPI/ippi_appendices/ippi_appA_Intro.htm

Paul

[igorastakhov]

Hello Ben,

NAN means "not a number" - so there is no any defined arithmetic/comparison/etc operation for it in IEEE or IA. If you've got a NAN in your application/data - it means a bug in your application. IPP is performance oriented library and it can't check every input vector element for NAN - it's users' responsibility to provide correct input data. You see from Ivan's answer above that it's rather tricky to detect NANs and you are the first customer who've asked for special function for NANs processing. I guess you should check the source of your data and correct it before applying IPP.

Regards,
Igor

[Ben_Young]

Hi Igor,

That's absolutely not my understanding of how NaNs are supposed to work. qNaNs do not indicate a bug in the application, they simply indicate that an operation has produced a NaN result (e.g. Inf * 0), and that NaN is then supposed to flow through the system. This is our experience in C, C++, C#, and Python and is backed by the wikipedia article on IEEE NaNs:

"Floating point operations other than comparisons normally propagate a quiet NaN (qNaN). Floating point operations on a signaling NaN (sNaN) signal an invalid operation exception, the default exception action is then the same as for qNaN operands and they produce a qNaN if producing a floating point result.

A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN. The other standard comparison predicates all signal if they receive a NaN operand, the standard also provides non-signaling versions of these other predicates. The predicate isNaN(x) determines if a value is a NaN and never signals an exception.

The propagation of quiet NaNs through arithmetic operations enables errors to be detected at the end of a sequence of operations without extensive testing during intermediate stages."

As our application is a very high performance risk engine, continously checking for overflow conditions would greatly reduce our performance, and we deliberately let NaNs propogate for the end user to consider. If IPP considers NaNs a "bug" we may have to reconsider our use of it...

[Ben_Young]

Thanks Paul,

I'll take a look. I'm relieved IPP does have some policy in this area!

Thanks,

Ben

[PaulF_IntelCorp]

Hello Ben,

Just a note that your issue has been converted into a related feature request for the next major release of the product, effectively: "a function that detects and/or cleans a vector/matrix of problem values (such as NaN, infinity, etc.)."

Regards,

Paul

[Ying_H_Intel]

Hi Ben,

Not sure if the workaround to checking the NAN of input  Ivan mentioned works for your project.  As checking the NaN in input is very expensive for IPP too regarding high performance, our product team decided not to implement the feature. Anyway, thank you for raising the problem.

Thanks

Ying