[Octave-bug-tracker] [bug #40668] -NA is inconsistent with other operations on NA

[Daniel Kraft]

Follow-up Comment #2, bug #40668 (project octave):

The problem here seemingly is that the unary minus changes the sign bit, which
makes Octave no longer recognise its special NaN-pattern for NA.  A possible
fix is to change __lo_ieee_is_NA to check for both patterns (the original one
and the one with inverted sign bit), like this:

int
__lo_ieee_is_NA (double x)
{
#if defined (HAVE_ISNAN)
  lo_ieee_double t;
  t.value = x;
  return (isnan (x) && (t.word[lo_ieee_hw] == LO_IEEE_NA_HW ||
t.word[lo_ieee_hw] == 0xFFF840F4)
          && t.word[lo_ieee_lw] == LO_IEEE_NA_LW) ? 1 : 0;
#else
  return 0;
#endif
}

(This is of course not a properly done patch, just a quick hack to try it
out.)

Since I'm not an expert with IEEE floating-point numbers and things like that:
 Is this the correct way to fix this bug, or should we rather add a check to
unary minus operations so that they don't invert the sign bit in case of NA? 
This, however, seems to me as if it would hurt performance for each and every
unary minus operation, and would also possibly have to be done in all the
different implementations of unary minus (for scalars, complex values,
matrices, sparse matrices and so on).  Thus to me the change of isna() seems
better.

If this sounds like a good approach, I will write a nicer patch (including
some comments) and provide a hg commit diff.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40668>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/