(j3.2006) (SC22WG5.5782) [ukfortran] edits to clarify SQRT treatment ofnegative zero, for comments
Anton Shterenlikht
mexas
Wed Aug 24 04:47:07 EDT 2016
>From: "Cohen Malcolm" <malcolm at nag-j.co.jp>
>
>I would prefer to leave the "principal value" wording alone.
>
>I also prefer to leave the "When the real part of the result is zero"
>wording alone. Unless you enjoy posing maths questions of people reading
>the standard to work out whether anything changed.
>
>I also don't think this is necessary - the likely reason vendors did not
>spot the change in semantics from previous Fortran standards (77 and 90 both
>forbid negative real zero being treated differently from positive real zero)
>is just that the change in semantics occurs without any wording change in
>SQRT itself. That is, the word "sign" in the description does not refer to
>the SIGN intrinsic directly, however since the SIGN intrinsic returns the
>"Magnitude of A with the sign of B", it is clear that "the same sign as" a
>distinguished negative real zero means a negative value. It could well be
>more effective to point out to the offending vendor(s) that they overlooked
>this Fortran 95 change in semantics than to edit SQRT like this. (I don't
>actively object to editing SQRT to make it more obvious though, if that's
>what people want; just that it's not necessary.)
[56:21-25 4.4.3.2p3] is very clear on the rules:
"Processors that distinguish between
positive and negative zeros shall
treat them as mathematically equivalent
...
as actual arguments to intrinsic procedures
other than those for which it is
explicitly specified that negative
zero is distinguished."
SQRT does not "explicitly specify" that
negative zero is distinguished.
Implicitly, following the SIGN logic, yes.
But not explicitly. So strictly following
[56:21-25] SQRT does not distinguish between
positive and negative zero.
So it seems to me
the wording must be changed to
explicitly specify that negative zero
is distinguished.
>The paper needs to add text to the Fortran 90 compatibility and Fortran 77
>compatibility subclauses to mention the change in semantics (close to where
>we talk about SIGN).
I understood the logic of compatibility
subclauses as accumulative, i.e.
Fortran 90 compatibility clause lists
only differences not already mentioned
in the preceding subclauses for f95 and f03.
Is that wrong? Is the aim to list the full
list of differences between f08 and f77
under Fortran 77 compatibility?
>Finally, with luck and a fair breeze 16-007r2 should be available early
>September so I recommend waiting until then so that you can produce edits
>against what will be the actual live draft.
Thank you
Anton
More information about the J3
mailing list