I quickly tried but sorry it provides no gains: Float.isNaN() is just
implemented as (a != a) so it is faster with only 1 condition (a != a)
than 2 (intval == 0 && (a != a)).
Another way to make NaN tests fall out naturally from your code is to
make sure that they are always in the "numeric test failed" branch.
Currently you have them in the "numeric test succeeded branch. What if
you inverted the test? As in:
if (a > intpart
&& CHECK_OVERFLOW && !overflow)
{
return intpart +/- 1;
}
return intpart;
In this case NaN causes the first test to fail and you jump straight to
the "return intpart" code without having to explicitly test for it...?
Basically we tend to have tests of the form "if (number is bad) return
failure" and NaN isn't caught by that. If we instead use "if (number is
good) { do things }" then NaN values will fail to make it into the code
block. Usually when these are at the top of a function we'd rather test
for bad values and return instead to avoid extra indenting, but then an
alternate way is to use:
if (number is good) {
[*]
} else {
return failure;
}
[*] no code there, we only really needed the else, or:
if (!(number is good)) {
return failure;
}
But, if the code block is small and has no further indentation needs,
then generally the following is naturally NaN-resistant:
if (numbers are good) {
// do all the calcs...
}
...jim
