From octave-sources-request at bevo dot che dot wisc dot edu  Mon Jul 24 16:39:30 2000
Subject: Re: Patch for nan/inf support without HAVE_*... 
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: octave-sources at bevo dot che dot wisc dot edu
Date: Mon, 24 Jul 2000 16:39:54 -0500

[This is not really the right place for discussions, but I noticed that
the response to my private reply was posted to the list, so I thought
that people should see my comments.  --jwe]

On 24-Jul-2000, Edward Jason Riedy <ejr at EECS dot Berkeley dot EDU> wrote:

| And "John W. Eaton" writes:
|  - 
|  - Can you explain what problem your patch is trying to solve?
| 
| 1) Correctness.  NaNs and Infs can still occur even when Octave's 
| configuration process decides that xisnan and relatives should 
| always return false.  External libraries like LAPACK will 
| certainly generate them.
| 
| 2) Completeness.  NaNs and +/-Inf are essential for a complete 
| algebra.  I haven't checked +/-0 consistency or how -Inf is
| handled yet.
| 
| 3) Killing off #ifdef tests.  The HAVE_ISNAN, etc. aren't
| necessary in most places.

I think it is reasonable to assume that a system that has complete
support for IEEE floating point would provide isnan and isinf or
finite, so I don't have a problem with the current implementation.

If a system allows IEEE NaNs and Infs to be represented, but doesn't
fully support them (Alphas running Unix but with old versions of GCC,
for example) then no matter what you do, IEEE floating point math is
not going to be fully functional.  For example, on an Alpha running
Digital Unix and using an old gcc (no support for IEEE math modes)
then it is possible to store Inf or NaN, but impossible to do anything
with them.  In that case, something like

  double tmp = 2.0 * x;

will trap if x is NaN or Inf.

So on systems that don't have proper support for IEEE floating point,
the current code should not cause crashes, but I think your changes
could.

Fortunately, there are not many such systems in use today (I don't
think many (any) Octave users are running it on VAX systems, and
Octave doesn't work on Alphas running VMS, or IBM 370 systems, as far
as I know).

| There may well be problems with the patch, but I don't have access 
| to hardware lousy enough for me to test it thoroughly.  Someone 
| with a VAX or IBM 370 might find a defect, although I believe 
| everything should pass through cleanly.  I don't know their 
| behavior on overflow, so that may be a problem.

Your code would probably compile OK, but it would probably not work as
you expect, at least on a VAX running some Unix variant since
overflows generate floating point exceptions, and if I remember
correctly, even though SIGFPE can be caught, I don't think it can be
repaired so that execution can continue, so there is nothing to do but
attempt to exit gracefully.

At least on the Alpha with old versions of gcc, you can attempt to
continue, but it is not really something we need to try to work around
now, because people can just get the current version of gcc, which
does support IEEE floating point Inf and NaN (and has for several
years now).

jwe



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------