[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lo_ieee_init: unrecognized floating point format! on ARM platform (revis
John W. Eaton
lo_ieee_init: unrecognized floating point format! on ARM platform (revisited)
Fri, 2 Feb 2007 04:36:49 -0500
On 10-Jan-2007, Simon Pickering wrote:
| The values returned by Octave (either using format bit, or the patched
| version of machar) on the Nokia 770 are as follows:
| eps 2.2204460492503131e-16 0 3CB00000
| epsneg 1.1102230246251565e-16 0 3CA00000
| xmin 4.9406564584124654e-324 1 0
| xmax inf 0 7FF00000
| So xmax and xmin differ.
| I have a couple of questions:
| Why is this endianness check carried out at run-time rather than at compile
| time (in configure for example, as R does)?
Because a configure-time check will fail when cross compiling.
| Is the test designed to test the endianness, or the correctness of the fp
| implementation. I ask because I think there are simpler ways to check
| endianness if that's all that's needed.
We need to know whether it is IEEE big/little endian. If your system
really does implement one of these, then it is surprising that xmax
and xmin are different. In particular, xmax looks wrong because it
should not be Inf. What does paranoia compute for these values?
Maybe the bug is in the machar code used by Octave to generate them.
- lo_ieee_init: unrecognized floating point format! on ARM platform (revisited),
John W. Eaton <=