lo_ieee_init: unrecognized floating point format! on ARM platform (revisited)

[John W. Eaton]

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.

jwe