Re: On writing negative zero - with or without sign

On Jul 8, 1:14 pm, Jerry DeLisle <jvdeli...@xxxxxxxxxxx> wrote:
Fortran 77 explicitly forbids output of a negative sign for a
zero value.

Fortran 90/95 are intended to be compatible with F77 except
where noted. The f90/95 standards omit the statement about not
outputting the negative sign for a zero value.

The statement to which I believe you are referring appeared in
FORTRAN 77, was retained in Fortran 90, and was dropped in
Fortran 95. That statement was not present in the FORTRAN 66
standard, but the FORTRAN committee interpreted the language of
that standard as forbidding prefixing the external representation
of a zero value with a minus sign. See interpretation #52 in
"Clarification of FORTRAN Standards - Second Report" by
C. Kerpelman, CACM 14, 10 (October 1971).

I preparing a patch to gfortran to print the sign for zero values
if the signbit is set.

My question is: Should gfortran default behavior omit the negative
sign and only show it with a special compiler flag or should the
default behavior be to show the negative sign.?

Example code:

REAL :: x,y
character(len=16) :: s1,s2
x=-0.0
y= 0.0
IF (sign(1.0,x).NE.sign(1.0,y)) THEN
write(s1,'(E16.8)') x
write(s2,'(A16)') "-0.00000000E+00"
print *, s1
print *, s2
ENDIF

END

At the moment gfortran does not print the negative sign for x.
I am providing that capability, but need interpretation of the
standards.

The Fortran standards (66, 77, 90, 95, and 2003) as written
forbid prefixing a zero value with a minus sign, even if the
processor distinguishes between positive and negative zeros.
The sense of the current membership of J3 is that the minus
sign should be allowed. Because the members of the committee
do not want to rewrite the standard to say what they think it
should mean, they choose to apply a remarkably contorted
interpretations to the standard as written.

There is an official interpretation request on this issue, but
J3 has made no progress on it.

In any case, Section 4.4.2 of the Fortran 2003 states

The real type includes a zero value. Processors that
distinguish between positive and negative zeros shall
treat them as equivalent

(1) in all relational operations,

(2) as actual arguments to intrinsic procedures
other than those for which it is explicitly
specified that negative zero is distinguished,
and

(3) as the scalar-numberic-expr in an arithmetic IF.

That statement establishes that there is a zero value and that
processors may distinguish between positive and negative zeros.

Section 10.6.1 states

(3) On output with I, F, E, EN, ES, D, and G editing,
the representation of a positive or zero internal
value in the field may be prefixed with a plus sign,
as controlled by the S, SP, and SS edit descriptors
or the processor. The representation of a negative
internal value in the field shall be prefixed with
a minus sign.

That statement establishes that zero and positive values are
treated the same for formatted output.

How do members of J3 justify treating zero values as negative
values, given the statements quoted above? One member of the
committee has claimed that positive and negative zeros are not
zero values, that they are positive values or negative values.
That interpretation makes the statement cited from Section 4.4.2
irrelevant.

At least two members of the committee have latched on to the
word "may" in the statement cited from Section 10.6.1. They
take the use of that word as meaning that positive and zero
values "may be prefixed with a plus sign, as controlled by the
S, SP, and SS edit descriptors or the processor," but, then again,
they may not. They too have to interpret negative zeros as
negative values to complete their interpretation, but they have
only the burden of saying that a negative zero is both a zero
value and a negative value, not the burden of having to say that
a negative zero is not a zero value. Of course, this line of
interpretation opens the possibility of prefixing the external
representation of a zero value with both a plus sign and a minus
sign.

I believe the standard should allow an implementation to prefix
the external representation of a zero value that the processor
recognizes as a negative zero with a minus sign. I differ with
at least some members of the committee in that I do not believe
the standard as it is currently written allows that for the
reasons given above.

Bob Corbett

.

Relevant Pages

  • Re: Requesting advice how to clean up C code for validating string represents integer
    ... Linkname: c standard - clc-wiki ... with a signed zero (including all IEC 60559 implementations) ... that follow the specification of annex G, the sign of zero ... between brake pedal and brake pads being through a complicated ...
    (comp.lang.c)
  • Re: Newbie question about double precision
    ... > equal to zero. ... In Fortran, KINDs are ... and that was duly noted in the new standard and the books ... would specify all variables and constants in a given scoping unit to be of a ...
    (comp.lang.fortran)
  • Re: NULL and zeros
    ... The machine's bizarre internal representation does not excuse the implementation from its obligations. ... standard. ... The standard indeed does not specify what an "all bytes zero" or "all ... the originator of this calloc() is clueless -- my personal ...
    (comp.lang.c)
  • Re: writing negative zero
    ... >> the Fortran and Fortran 95 standards, ... >> be written using a minus sign by a standard conforming Fortran 95 ... >write negative zeros with a leading minus sign, ... SZ (where Z stands for zero) to force - when outputting negative zero. ...
    (comp.lang.fortran)
  • Re: Redux: Was there a negative real zero possibility in early Fortran?
    ... The FORTRAN 66 standard said that the result of the SIGN ... standard required that any zero value as the second argument, ... save the format statement and then modify it so as ...
    (comp.lang.fortran)