(j3.2006) IEEE comparisons

[Robert Corbett]

On 8/23/2016 12:23 AM, Cohen Malcolm wrote:
> Hi Robert,
>
> Thanks for that.
>
> I still think that we would satisfy those requirements simply by saying that
> e.g. compareQuietLess(X,Y), with Y a less precise format than X, is provided
> by IEEE_QUIET_LT(X,IEEE_REAL(Y,KIND(X))).  And compareSignalingLess(X,Y) is
> provided by X<IEEE_REAL(Y,KIND(X)), or indeed just X<Y.
>
> The issue of multiple signals looks like a red herring for us.  This being a
> single Fortran expression there is no way for a standard-conforming Fortran
> program to "count" the number of times IEEE_INVALID is raised during its
> evaluation.  Raising it 27 times just ends up with the flag being .TRUE..
> (Attempting to use C signal to count fails, as C makes resumption after
> SIGFPE "undefined behavior" i.e. anything goes.)  This would appear to be
> true whether we have mixed-format IEEE_* comparisons or whether we say that
> they are provided by the circumlocution above.
>
> If you do not agree with my analysis I would like to know how it is that one
> can count exceptions in a single expression.

I believe you are correct.  While I could easily create a program
using Oracle Developer Studio Fortran or Oracle Developer Studio C
that counts exceptions, I would need to use features not provided
by the language standards to do it.  ISO/IEC/IEEE 60559:2011
recommends that languages provide such features, but it does not
require languages to provide them.

> My main objection to providing the mixed-format comparisons directly is that
> this multiplies the already-large number of predicate functions that the
> vendor needs to provide by the square of the number of real kinds (of a
> single radix).  If some real kinds are not IEEE-conforming they would still
> need to be provided (they are allowed to be referenced by the source code as
> long as they are not invoked during execution).  This seems like
> disproportionate effort for something of rather limited usefulness for which
> an adequate (if slightly more verbose) alternative is available.
>
> It might also be argued that the user ought to be made to write the
> conversion explicitly in these cases.
>
> I am not adamantly opposed here; just that the costs seem to outweigh the
> likely benefits.

My reason for wanting to allow the forms allowed by
ISO/IEC/IEEE 60559:2011 is to satisfy the requirements of
that standard.  I do not think anyone outside of people
who write test suites and people trying to find "gotcha"s
will use the function forms of comparisons.  Who is going
to write "IEEE_SIGNALING_GE(X, Y)" instead of "X .GE. Y"?
(Rhetorical)

On a slightly different topic, ISO/IEC/IEEE 60559:2011
forbids replacing the expression

       .NOT. (X .LT. Y)

with

       X .GE. Y

(see the last paragraph of Subclause 5.11).
Subclause 7.1.5.4.2 allows a logical expression to
be evaluated as any other expression that is
logically equivalent.  I assume that that means
the optimization is allowed unless IEEE_SUPPORT_NAN
is true for X and Y.  Do we need to say something
about that?

Bob Corbett