The assignment of 1.4013E-45F to the variable 'absxk' could be causing an underflow. This happens on targets that do not support subnormal floating-point numbers. However, C compilers, for such targets, may complain that a subnormal literal is not valid. The MATLAB language requires IEEE floating point with support for denormal floating-point numbers in some contexts.
This literal arises from code generation for the MATLAB eps() function. The smaller of the two literals is eps(single(0)).
>> eps(single(0))
ans =
single
1.401298e-45
The larger of the two is realmin(single(0))
>> realmin('single')
ans =
single
1.175494e-38
1. Why is this assignment generated in the code?
The reason this code is generated by ismember() is that the function is protecting itself against the possibility of some data being kept by the C compiler in extended precision registers. In some situations, like that, with some C compiler options, the register value and in-memory values might differ, so a ~= b, when they would be equal if the value in the register were flushed to RAM before performing the equality check. Some coding standards forbid floating-point equality checks (e.g. MISRA). So the code is determining that a == b when abs(b - a) <= eps(a/2).
2. How can this be avoided?
In the context of usage of ismember() or any of the other set functions on floating-point data, please consider whether the data really needs to be floating point. If an integer type can be used instead, the function will be vastly more efficient than using ismember on a floating point quantities that have integer values. The best option if the inputs are floating point integers, or a small multiple of them are integers, is to use an integer type like int32, although this can be contraindicated if it produces or requires a lot of data copies.
