(j3.2006) IEEE comparisons
Cohen Malcolm
malcolm
Tue Aug 23 03:23:35 EDT 2016
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.
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.
As I understand it, the IEEE 754 committee is working on replacing the
current standard, and as I understand their schedule, this is unlikely to
occur before our finalisation (especially for the ISO/IEC/IEEE 60559
version). And as I understand the rules, they are not going to be able to
issue an erratum for the one we are binding to (the current one). Given all
that, should it in fact be possible for a conforming Fortran program to
detect the difference, I would be somewhat more opposed to adding a facility
which, compared to the current circumlocution, would allegedly require even
more work from the vendors and have a negative performance impact to boot.
Cheers,
-----Original Message-----
From: Robert Corbett
Sent: Tuesday, August 23, 2016 2:58 PM
To: j3 at mailman.j3-fortran.org
Subject: Re: (j3.2006) IEEE comparisons
On 8/22/2016 12:17 AM, Cohen Malcolm wrote:
> I do not think this is a problem, because the Fortran standard already
> handles this in the way you prefer, viz
>
> "if the operands have different types or kind type parameters, the
> effect
> is as if each operand that differs in type or kind type parameter from
> those
> of the result is converted to the type and kind type parameter of the
> result
> before the operation is performed"
>
> therefore multiple exceptions are already permitted. That is, because of
> that sentence, we never invoke the mixed-format versions of the IEEE
> comparisons, only the same-format versions.
I think the text you meant to quote is in paragraphs6 and 7
(which should be one paragraph) of Subclause 7.1.5.5.1 of
of 16-007r1. That text states
In the numeric relational operation
/x_1 rel-op x_2 /
if the types or kind type parameters of x_1 and x_2
differ, their values are converted to the type and
kind type parameter of the expression x_1 + x_2
before evaluation.
I do not propose any change to that text (aside from fixing
the paragraph numbering).
Subclause 5.6.1 of ISO/IEC/IEEE 60559:2011 states
Implementations shall provide the following
comparison operations, for all supported
floating-point operands of the same radix in
arithmetic formats:
Subclause 5.11 states
Additionally, floating-point data represented
in different formats shall be comparable as
long as the operands' formats have the same
radix.
I intend to provide edits to modify the comparison
functions specifiedin Clause 14 of 16-007r1 to
satisfy those requirements.Please let me know if
that change is unacceptable.
I spoke with David Hough today(Monday). He said that
the IEEE Std. 754 committee will be meeting this coming
Friday and that my questions about comparisons are on
the agenda. I hope to have answers to my questions soon.
Bob Corbett
> Cheers,
>
> -----Original Message-----
> From: Robert Corbett
> Sent: Tuesday, August 16, 2016 3:08 PM
> To: j3 at j3-fortran.org
> Subject: (j3.2006) IEEE comparisons
>
> While working on my paper concerning the IEEE relational
> operators and predicate functions, I noticed some flaws
> in IEEE Std. 754:2008. Most of them are irrelevant for
> Fortran, but one is a potential problem.
>
> The current wording of the standard indicates that the
> comparison operations should generate at most one exception.
> That is fine for comparisons when the operands have the
> same format, but it is a problem when the operands have
> different formats. The arithmetic operands have similar
> issues, but the standard explicitly allows the arithmetic
> operations to be implemented as a sequence of other
> operations. The standard makes no such allowance for the
> comparison operations. I see how to implement comparisons
> so that they conform to the current version of the
> standard, but at a significant cost in performance.
>
> I asked David Hough to take up the question of whether the
> inhomogenous comparison operations can signal more than once
> with the IEEE committee. He thinks it is likely, but not
> certain, that the committee will decide that the operations
> can signal more than once.
>
> I found one of the issues addressed in the errata for
> IEEE Std. 745:2008 amusing. Suppose a program includes an
> edit descriptor for producing one decimal digit under an
> E format. What value should be printed for the internal
> value 95.0 under the round-to-nearest-even rounding mode?
>
> Bob Corbett
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star.
> ________________________________________________________________________
>
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________
--
........................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3
mailing list