[Octave-bug-tracker] [bug #59830] Architecture-dependent results for arithmetic operations involving NA

[Rik]

Follow-up Comment #6, bug #59830 (project octave):

I suspect there isn't going to be a good solution.

See the file liboctave/utils/lo-ieee.h.

Octave defines an NA value to be composed of two 32-bit values.


#define LO_IEEE_NA_HW 0x7FF840F4
#define LO_IEEE_NA_LW 0x40000000


The routine that decides whether something is NA versus NaN is


int
__lo_ieee_is_NA (double x)
{
  lo_ieee_double t;
  t.value = x;
  return (__lo_ieee_isnan (x) && t.word[lo_ieee_hw] == LO_IEEE_NA_HW
          && t.word[lo_ieee_lw] == LO_IEEE_NA_LW) ? 1 : 0;
}


The IEEE standard defines NaN as having the sign bit cleared, maximum possible
exponent, and a mantissa which is non-zero.  Thus, the high word begins with
0x7FF.  Most mathematical libraries detect NaN and then don't further process
the number.  So when you operate on an NA value in an IEEE-compliant library
the value just passes through.  However, this is implementation dependent.  My
guess is that the ARM software library, or hardware implementation, detects
that the value is a NaN and then substitutes a constant NaN value such as
0x7FF80000.  This value is also NaN according to IEEE standards, but it is no
longer an Octave NA because the values have changed.  If you can compile with
a debugger you could check whether this is correct.

There may be special switches you can throw during compilation to determine
how IEEE operations are implemented (such as not using 80bit precision, etc.).
 Maybe there is something that might be useful for MIPS?  In gcc, for example,
I see '-mhard-float' to require use of HW math co-processor and '-msoft-float'
to use software libraries for floating point.

This option also looks promising


-mnan=2008
       -mnan=legacy
           These options control the encoding of the special not-a-number
(NaN) IEEE 754 floating-point
           data.

           The -mnan=legacy option selects the legacy encoding.  In this case
quiet NaNs (qNaNs) are
           denoted by the first bit of their trailing significand field being
0, whereas signaling NaNs
           (sNaNs) are denoted by the first bit of their trailing significand
field being 1.

           The -mnan=2008 option selects the IEEE 754-2008 encoding.  In this
case qNaNs are denoted by
           the first bit of their trailing significand field being 1, whereas
sNaNs are denoted by the
           first bit of their trailing significand field being 0.


If you can verify with a debugger first I think that would be the best first
step.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59830>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/