(j3.2006) (SC22WG5.5783) [ukfortran] edits to clarify SQRTtreatment ofnegative zero, for comments

[Cohen Malcolm]

1. There is no negative zero as an actual argument to complex SQRT.  The 
actual argument is the complex value and this is not a negative real zero, 
in fact it is not even real.  If it was otherwise this would be a NEW 
FEATURE requiring WG5 approval.  A careful reading of the current text 
already reveals the answer you want, it is not ambiguous, contradictory, or 
even wrong.

So the edit to SQRT is not strictly necessary, though as I said I do not 
actively object.

I do think you should first report non-compliant behaviour direct to the 
vendors concerned though, as this is going to be the quickest way to get the 
situation corrected.

2. The "logic" of the compatibility subclauses, is that they describe the 
incompatibilities.  I do not know why you think they are "accumulative" 
since each one fully describes the incompatibilities between F2015 and the 
referred-to older standard.  Please read the F90 and F77 subclauses both of 
which correctly describe the incompatibility with SIGN.  This needs to be 
done in a similar fashion for SQRT.

Cheers,

-----Original Message----- 
From: Anton Shterenlikht
Sent: Wednesday, August 24, 2016 5:47 PM
To: sc22wg5 at open-std.org
Subject: [ukfortran] (SC22WG5.5782) (j3.2006) edits to clarify SQRTtreatment 
ofnegative zero, for comments

>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

_______________________________________________
ukfortran mailing list
https://lists.accu.org/mailman/listinfo/ukfortran

-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.