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.

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.

Thanks,

Jerry

Just my opinion, but I'd recommend that you print the minus sign.
I don't even see a need to have an option to turn it off.  It's not
like any old programs could be dependent on the behavior.  And
*new* programs might very well depend on getting the sign right.

I the very old days (even before ANSI, the organization was
ASA - the American Standards Association), there was a minor
standard that specified the presentation of printed technical
information (I've got a copy somewhere).  For whatever reason,
they decided that if all the displayed digits were zero a negative
sign should not be permitted -  even if the value in question was
*not* zero, but the value merely underflowed the decimal
field in which the data was printed.  Well, the first Fortran
standard chose that same rule in order to be consistent with
that other standard.  It was always a bad idea.

The IEEE floating point standard recommends the opposite.
The display of a value, even if it does compare equal to zero,
should preserve the sign.  An F2003 implementation consistent
with IEEE float must do that.  So, if you plan to support that
part of F2003, you should keep the sign of zero.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

Jerry DeLisle 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.

One Fortran system that I used in the Fortran 66 days printed a '+'
sign on a negative zero, and only on a negative zero.  I don't
remember now why I found that out, but it was pretty surprising
at the time.

That would seem to satisfy even standard that prohibit a '-' sign.

-- glen

James Giles wrote:
> Just my opinion, but I'd recommend that you print the minus sign.
> I don't even see a need to have an option to turn it off.  It's not
> like any old programs could be dependent on the behavior.

The NIST testsuite is, apparently. To which extent that is
representative of real F77 applications, I don't know.


-- 
Janne Blomqvist

Janne Blomqvist wrote:
> James Giles wrote:
>> Just my opinion, but I'd recommend that you print the minus sign.
>> I don't even see a need to have an option to turn it off.  It's not
>> like any old programs could be dependent on the behavior.
>
> The NIST testsuite is, apparently. To which extent that is
> representative of real F77 applications, I don't know.


Well, given that it's a test suite, it's dependency is probably
that it was deliberately written to test whether zero has a
negative sign printed with it.  My guess is that it has no
further meaning than that.

The standard has already changed once. It used to be required
that an output of entirely zero digits must not have a minus sign.
And now (as of F95 I think) if the internal value is negative (other
than negative zero) the output field must have a minus sign - even
if the only digits actually output are zeros.  Headway occurs slowly.
I can't find it quickly, but I think F2003 requires the minus sign if
the implementation is IEEE and the internal value is a negative zero.

As the standard changes, test suites will too.  In the meantime
dropping the sign of zero is a numerically unfriendly act.  I still
recommend keeping the sign without options to turn it off.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:
> Janne Blomqvist wrote:
>> James Giles wrote:
>>> Just my opinion, but I'd recommend that you print the minus sign.
>>> I don't even see a need to have an option to turn it off.  It's not
>>> like any old programs could be dependent on the behavior.
>> The NIST testsuite is, apparently. To which extent that is
>> representative of real F77 applications, I don't know.
> 
> 
> Well, given that it's a test suite, it's dependency is probably
> that it was deliberately written to test whether zero has a
> negative sign printed with it.  My guess is that it has no
> further meaning than that.
> 
> The standard has already changed once. It used to be required
> that an output of entirely zero digits must not have a minus sign.
> And now (as of F95 I think) if the internal value is negative (other
> than negative zero) the output field must have a minus sign - even
> if the only digits actually output are zeros.  Headway occurs slowly.
> I can't find it quickly, but I think F2003 requires the minus sign if
> the implementation is IEEE and the internal value is a negative zero.
> 
> As the standard changes, test suites will too.  In the meantime
> dropping the sign of zero is a numerically unfriendly act.  I still
> recommend keeping the sign without options to turn it off.
> 
Thanks for input.  Presently gfortran does not give the sign and I am patching 
it to do so by default.

On Jul 8, 1:14 pm, Jerry DeLisle <jvdeli...@verizon.net> 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

<robert.corbett@sun.com> wrote:

> 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.

I disagree with the characterization of both the motives and the alleged
contortion.

> In any case, Section 4.4.2 of the Fortran 2003 states
.... 
> That statement establishes that there is a zero value and that
> processors may distinguish between positive and negative zeros.

Yes.

> 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.

I see no wording that says "the same" or anything like that.
 
> 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.

Well. We are clearly getting off into individual opinions here. I do
note that Bob was careful to say "one member". Don't overlook that when
reading. One member is not particularly close to a majority. In fact,
that would be insufficient for a second. I'm not quite sure what member
he is talking about. But it doesn't really matter. Remember that
committee membership is not particularly difficult to get. The statement
that "one member" claims something is a lot like saying that "one
person" claims something.  You can find one person who will claim almost
anything; I'm not sure that the "almost" qualifier is even needed. I've
bitched here before about people trying to give increased credence to an
otherwise anonymous citation by saying that "a committee member" said
something.

If we were playing that game, I could raise with a "the editor said",
but I think I'll stick with the technical arguments.

> 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.

I'm one of the members who indeed think that the word "may" means "may",
but the above is an inaccurate representation of the position. The "but
then again they may not" doesn't make sense to me as particularly
related. As one of the people who I presume Bob is citing, I think I get
some say in what I said. It wasn't that. Of course it might not (I'd say
"might" instead of "may" for this usage, but that's a quibble). There
never has been the least bit of question about the fact that there might
be no prefix at all. In fact, with SS, there is required to be no prefix
for positive values.

The point was that the above says that "a zero internal may be prefixed
by a plus sign, as controlled". However, that statement is not
exclusionary. It doesn't say that a zero may not ever be preceeded by a
minus sign.

In fact, since the above quote explicitly says that a negative value is
prefixed with a minus sign, I find it difficult to interpret it any
other way. A negative zero is negative. If you want to claim otherwise,
then I'm going to say you have pot/kettle/black problems in talking
about contorted interpretations.

The line about how a zero may be prefixed with a plus is perhaps not
perfectly clearly written, in that it doesn't make the parallel
statement that a zero may be prefixed by a negative sign in some cases,
but it at least does not contradict that possibility.

 > They too have to interpret negative zeros as
> negative values...

Um, yes. I interpret the modifier "negative" to mean "negative". There
are systems that don't have a negative zero, but for ones that have one,
it is negative. That's why it is called, coincidentally, a negative
zero.

> 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.

Only if you go out of your way to read perversely. I think that is a lot
more convoluted reading than the argument that the "negative" in
"negative zero" doesn't mean that it is negative.

> 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.

Me too.

>  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.

That's where I disagree with you. I think the standard already says
that. I think its wording is less than ideal, but I think that's what it
says. No, I did not say or think that I "do not want to rewrite the
standard to say what they think it should mean". I'll speak for myself,
thank you. I have never said or thought that, and I find that a
prejudicial misstatement of my position.

What I do think is that the standard already says that, but it is poorly
worded and should be clarified in future versions. I note that in
general, the interpretation process is not supposed to rewrite prior
standards for clarity. It is supposed to rewrite only to correct errors.
Clarifications are issued as interpretations and become candidates for
improved wording in subsequent versions.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> In a description regarding the ethernet standard, Rich Seifert
> (who is on the ethernet standards committee) indicates in one
> of his books that only "shall" statements actually mean anything,
> and that "may" is a synonym for "may not".

ISO, which is the organization responsible for the standards in
question, has a document that explicitly covers such terms. ISO
Directive 3, if I recall correctly, though I don't feel like dragging it
out to check.

It is quite specific about the use of such terms. "May" indicates
permission. That does have definite meaning in a standard; that's why
ISO lists it. I think that "may not" indicates prohibition, though I'd
have to drag out my copy to be sure.

The possible confusions there are why I prefer "might" instead of "may"
to indicate what could be more elaborately stated as "might or might
not".

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

robert.corbett@sun.com wrote:

(snip regarding printing of negative zero)

> 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. 

In a description regarding the ethernet standard, Rich Seifert
(who is on the ethernet standards committee) indicates in one
of his books that only "shall" statements actually mean anything,
and that "may" is a synonym for "may not".

> 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.

With no "shall" other than for negative values, I suppose I
believe it is legal.  Then again, one could argue it legal for
positive values, too.  That would lose in "quality of implementation."

-- glen

Richard Maine wrote:

(snip on the meaning of "shall", "may", and "may not")

> ISO, which is the organization responsible for the standards in
> question, has a document that explicitly covers such terms. ISO
> Directive 3, if I recall correctly, though I don't feel like dragging it
> out to check.

"6.10.8 Use of words

The word �shall� shall be used to express mandatory requirements.
The word �may� shall be used to express optional requirements.
Although the negative form of �shall� is �shall not�, the negative
form of �may� is not �may not�, but is �need not�.
The use of �may not� shall be avoided."

> It is quite specific about the use of such terms. "May" indicates
> permission. That does have definite meaning in a standard; that's why
> ISO lists it. I think that "may not" indicates prohibition, though I'd
> have to drag out my copy to be sure.

http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/Itu-T/Rulesver10.doc

-- glen

On Jul 15, 9:46 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> "6.10.8 Use of words
>
> The word "shall" shall be used to express mandatory requirements.
> The word "may" shall be used to express optional requirements.
> Although the negative form of "shall" is "shall not", the negative
> form of "may" is not "may not", but is "need not".
> The use of "may not" shall be avoided."

It would seem that the opposite of "may" means the same thing
as "may," but with a different emphasis.

Bob Corbett

On Jul 15, 8:15 pm, nos...@see.signature (Richard Maine) wrote:
> <robert.corb...@sun.com> wrote:
> > 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.
>
> I disagree with the characterization of both the motives and
> the alleged contortion.

I call it as I see it.  I might be wrong, but that is how it
appears to me.

>
> > 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.
>
> I see no wording that says "the same" or anything like that.

No, but I see the phrase "the representation of a positive or zero
internal value."  It certainly seems to me that establishes that
they are treated the same.

> > 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.
>
> Well. We are clearly getting off into individual opinions here. I do
> note that Bob was careful to say "one member". Don't overlook that
> when reading. One member is not particularly close to a majority.
> In fact, that would be insufficient for a second. I'm not quite
> sure what member he is talking about. But it doesn't really matter.
> Remember that committee membership is not particularly difficul
> to get. The statement that "one member" claims something is a lot
> like saying that "one person" claims something.  You can find one
> person who will claim almost anything; I'm not sure that the
> "almost" qualifier is even needed. I've bitched here before about
> people trying to give increased credence to an otherwise anonymous
> citation by saying that "a committee member" said something.
>
> If we were playing that game, I could raise with a "the editor said",
> but I think I'll stick with the technical arguments.
>
> > 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.
>
> I'm one of the members who indeed think that the word "may" means
> "may", but the above is an inaccurate representation of the
> position.

You are indeed one of the two to whom I was referring.

> The "but
> then again they may not" doesn't make sense to me as particularly
> related. As one of the people who I presume Bob is citing, I think
> I get some say in what I said. It wasn't that. Of course it might
> not (I'd say "might" instead of "may" for this usage, but that's a
> quibble).

> There never has been the least bit of question about the fact that
> there might be no prefix at all. In fact, with SS, there is
> required to be no prefix for positive values.

Yes.  Furthermore, the SP edit descriptor requires that the
external representation of the value be prefixed by a plus sign.

> The point was that the above says that "a zero internal may be
> prefixed by a plus sign, as controlled". However, that statement is
> not exclusionary. It doesn't say that a zero may not ever be
> preceeded by a minus sign.

No, it does not say that.  It also does not say that a positive
value may not ever be preceded by a minus sign.

> In fact, since the above quote explicitly says that a negative value
> is prefixed with a minus sign, I find it difficult to interpret it
> any other way. A negative zero is negative.

Here we reach the foundation of the difference in our readings.
I interpret a real zero value as being neither positive nor
negative.  The standard has the right to say otherwise, but
it does not.

> If you want to claim otherwise,
> then I'm going to say you have pot/kettle/black problems in talking
> about contorted interpretations.

The usual rule in standards is that words have their conventional
meanings unless otherwise specified.  My dictionary gives as one
of its definitions of the word "negative"

    less than zero and opposite in sign to a positive number
    that when added to the given number yields zero

I'll stand by that definition, at least for the mathematical real
numbers.  If the committee chooses to define the word "negative"
differently for Fortran's real data type, the committee should
add some mention of it to the standard.  I would strongly advise
the committee to avoid doing so, and to clean up the problems
caused by negative zeros in another way.

I have, until now, interpreted the Fortran standard's use of the
terms "negative zero" and "positive zero" as equivalent to the
IEEE Floating-point standard's use of the symbols "-0" and "+0".
IEEE Std. 754 does not use the terms "negative zero" or "positive
zero."  I suspect that the authors of that standard would consider
those terms nonsensical.  It would have been better if the Fortran
committee had used the terms "plus zero" and "minus zero."  I see
now that the translation is getting in the way of clarity.

IEEE Std. 754 states

    For any variable that has the value zero, the
    sign bit s provides an extra bit of information.
    Although all formats have distinct representations
    for +0 and -0, the signs are significant in some
    circumstances, such as division by zero, and not
    in others.

The IEEE floating-point standard does not even hint that a
zero value should be considered positive or negative.  Indeed,
it would wreak havoc with that document were zero values to be
considered positive or negative, because postive and negative
values are nonzero values.

> The line about how a zero may be prefixed with a plus is perhaps not
> perfectly clearly written, in that it doesn't make the parallel
> statement that a zero may be prefixed by a negative sign in some
> cases, but it at least does not contradict that possibility.

As noted above, under the SP edit descriptor, the external
representation of a zero value must be prefixed by a plus sign.

>  > They too have to interpret negative zeros as
>
> > negative values...
>
> Um, yes. I interpret the modifier "negative" to mean "negative".

Until tonight I did not think that was what the Fortran standard
meant.  The concept of a real zero value being positive or negative
is sufficiently problematic, revisions of the Fortran standard should
explicitly call out what it means.

Bob Corbett

On Jul 15, 11:28 pm, robert.corb...@sun.com wrote:
> On Jul 15, 8:15 pm, nos...@see.signature (Richard Maine) wrote:
>
> > <robert.corb...@sun.com> wrote:
> > > 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.
>
> > I disagree with the characterization of both the motives and
> > the alleged contortion.
>
> I call it as I see it.  I might be wrong, but that is how it
> appears to me.
>
>
>
> > > 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.
>
> > I see no wording that says "the same" or anything like that.
>
> No, but I see the phrase "the representation of a positive or zero
> internal value."  It certainly seems to me that establishes that
> they are treated the same.
>
>
>
> > > 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.
>
> > Well. We are clearly getting off into individual opinions here. I do
> > note that Bob was careful to say "one member". Don't overlook that
> > when reading. One member is not particularly close to a majority.
> > In fact, that would be insufficient for a second. I'm not quite
> > sure what member he is talking about. But it doesn't really matter.
> > Remember that committee membership is not particularly difficul
> > to get. The statement that "one member" claims something is a lot
> > like saying that "one person" claims something.  You can find one
> > person who will claim almost anything; I'm not sure that the
> > "almost" qualifier is even needed. I've bitched here before about
> > people trying to give increased credence to an otherwise anonymous
> > citation by saying that "a committee member" said something.
>
> > If we were playing that game, I could raise with a "the editor said",
> > but I think I'll stick with the technical arguments.
>
> > > 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.
>
> > I'm one of the members who indeed think that the word "may" means
> > "may", but the above is an inaccurate representation of the
> > position.
>
> You are indeed one of the two to whom I was referring.
>
> > The "but
> > then again they may not" doesn't make sense to me as particularly
> > related. As one of the people who I presume Bob is citing, I think
> > I get some say in what I said. It wasn't that. Of course it might
> > not (I'd say "might" instead of "may" for this usage, but that's a
> > quibble).
> > There never has been the least bit of question about the fact that
> > there might be no prefix at all. In fact, with SS, there is
> > required to be no prefix for positive values.
>
> Yes.  Furthermore, the SP edit descriptor requires that the
> external representation of the value be prefixed by a plus sign.
>
> > The point was that the above says that "a zero internal may be
> > prefixed by a plus sign, as controlled". However, that statement is
> > not exclusionary. It doesn't say that a zero may not ever be
> > preceeded by a minus sign.
>
> No, it does not say that.  It also does not say that a positive
> value may not ever be preceded by a minus sign.
>
> > In fact, since the above quote explicitly says that a negative value
> > is prefixed with a minus sign, I find it difficult to interpret it
> > any other way. A negative zero is negative.
>
> Here we reach the foundation of the difference in our readings.
> I interpret a real zero value as being neither positive nor
> negative.  The standard has the right to say otherwise, but
> it does not.
>
> > If you want to claim otherwise,
> > then I'm going to say you have pot/kettle/black problems in talking
> > about contorted interpretations.
>
> The usual rule in standards is that words have their conventional
> meanings unless otherwise specified.  My dictionary gives as one
> of its definitions of the word "negative"
>
>     less than zero and opposite in sign to a positive number
>     that when added to the given number yields zero
>
> I'll stand by that definition, at least for the mathematical real
> numbers.  If the committee chooses to define the word "negative"
> differently for Fortran's real data type, the committee should
> add some mention of it to the standard.  I would strongly advise
> the committee to avoid doing so, and to clean up the problems
> caused by negative zeros in another way.
>
> I have, until now, interpreted the Fortran standard's use of the
> terms "negative zero" and "positive zero" as equivalent to the
> IEEE Floating-point standard's use of the symbols "-0" and "+0".
> IEEE Std. 754 does not use the terms "negative zero" or "positive
> zero."  I suspect that the authors of that standard would consider
> those terms nonsensical.  It would have been better if the Fortran
> committee had used the terms "plus zero" and "minus zero."  I see
> now that the translation is getting in the way of clarity.
>
> IEEE Std. 754 states
>
>     For any variable that has the value zero, the
>     sign bit s provides an extra bit of information.
>     Although all formats have distinct representations
>     for +0 and -0, the signs are significant in some
>     circumstances, such as division by zero, and not
>     in others.
>
> The IEEE floating-point standard does not even hint that a
> zero value should be considered positive or negative.  Indeed,
> it would wreak havoc with that document were zero values to be
> considered positive or negative, because postive and negative
> values are nonzero values.
>
> > The line about how a zero may be prefixed with a plus is perhaps not
> > perfectly clearly written, in that it doesn't make the parallel
> > statement that a zero may be prefixed by a negative sign in some
> > cases, but it at least does not contradict that possibility.
>
> As noted above, under the SP edit descriptor, the external
> representation of a zero value must be prefixed by a plus sign.
>
> >  > They too have to interpret negative zeros as
>
> > > negative values...
>
> > Um, yes. I interpret the modifier "negative" to mean "negative".
>
> Until tonight I did not think that was what the Fortran standard
> meant.  The concept of a real zero value being positive or negative
> is sufficiently problematic, revisions of the Fortran standard should
> explicitly call out what it means.
>
> Bob Corbett

On Jul 15, 11:28 pm, robert.corb...@sun.com wrote:

> I have, until now, interpreted the Fortran standard's use of the
> terms "negative zero" and "positive zero" as equivalent to the
> IEEE Floating-point standard's use of the symbols "-0" and "+0".
> IEEE Std. 754 does not use the terms "negative zero" or "positive
> zero."  I suspect that the authors of that standard would consider
> those terms nonsensical.  It would have been better if the Fortran
> committee had used the terms "plus zero" and "minus zero."  I see
> now that the translation is getting in the way of clarity.

I completed a scan of the C standard, and I found that it defines
and uses the term "negative zero," but the only in reference to
integer values.  The parts of the C standard that speak of
floating-point values use the terms "signed zeros," "+0," "-0,'
and "+/-0," where +/- is written as a single character.  My guess
is that the people who wrote the parts of the C standard concerning
floating-point values were more cautious in their terminology than
those who wrote the parts about integer values.

Bob Corbett

I wrote:

>> A negative zero is negative.

<robert.corbett@sun.com> wrote:

> Here we reach the foundation of the difference in our readings.
> I interpret a real zero value as being neither positive nor
> negative.  The standard has the right to say otherwise, but
> it does not.
> 
> > If you want to claim otherwise,
> > then I'm going to say you have pot/kettle/black problems in talking
> > about contorted interpretations.
> 
> The usual rule in standards is that words have their conventional
> meanings unless otherwise specified....

Yes. And the conventional meaning of an adjective is to modify what it
applies to. That is it is conventional that the term "negative zero"
refers to a zero that is negative.

You are quoting a definition that does not acknowledge the concept of a
zero being negative. Well, that's a fine definition for some purposes.
But it doesn't make sense when you are dealing with a number system that
explicitly incudes something called a negative zero.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jul 16, 12:41 am, nos...@see.signature (Richard Maine) wrote:
> I wrote:
> >> A negative zero is negative.
> <robert.corb...@sun.com> wrote:
> > Here we reach the foundation of the difference in our readings.
> > I interpret a real zero value as being neither positive nor
> > negative.  The standard has the right to say otherwise, but
> > it does not.
>
> > > If you want to claim otherwise,
> > > then I'm going to say you have pot/kettle/black problems in talking
> > > about contorted interpretations.
>
> > The usual rule in standards is that words have their conventional
> > meanings unless otherwise specified....
>
> Yes. And the conventional meaning of an adjective is to modify what it
> applies to. That is it is conventional that the term "negative zero"
> refers to a zero that is negative.
>
> You are quoting a definition that does not acknowledge the concept of a
> zero being negative. Well, that's a fine definition for some purposes.
> But it doesn't make sense when you are dealing with a number system that
> explicitly incudes something called a negative zero.
>
> --
> Richard Maine                    | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle           |  -- Mark Twain

>From a mathematical viwpoint:-

A zero value is a concept that is neither positive nor negative.
It is outside these two states, being the only member of a third
state.
(1-1/x) for all positive values of x yields a negative real value.
(1+1/x) for all positive values of x yields a  postive real value.

If a real value very close to zero has to be expressed in a limited
number of fractional digits, but these digits are all zeroes after the
decimal point, then the appropriate sign should be prefixed to the
values to indicate which side of absolute zero the values lies.

On Jul 16, 12:41 am, nos...@see.signature (Richard Maine) wrote:
> I wrote:
> >> A negative zero is negative.
> <robert.corb...@sun.com> wrote:
> > Here we reach the foundation of the difference in our readings.
> > I interpret a real zero value as being neither positive nor
> > negative.  The standard has the right to say otherwise, but
> > it does not.
>
> > > If you want to claim otherwise,
> > > then I'm going to say you have pot/kettle/black problems in talking
> > > about contorted interpretations.
>
> > The usual rule in standards is that words have their conventional
> > meanings unless otherwise specified....
>
> Yes. And the conventional meaning of an adjective is to modify what it
> applies to. That is it is conventional that the term "negative zero"
> refers to a zero that is negative.
>
> You are quoting a definition that does not acknowledge the concept of a
> zero being negative.

Exactly correct. The usual definition of negative does not admit
negative real zeros.

> Well, that's a fine definition for some purposes.

Yes.  For most of mathematics, for example.

> But it doesn't make sense when you are dealing with a number system
> that explicitly incudes something called a negative zero.

Right.  As I pointed out, the IEEE floating-point standard does
not mention positive and negative zeros.  It has zero values with
a sign bit.  The Fortran standard is free to use the terms
"positive zero" and "negative zero," but, to avoid confusion, it
should point out that it is using definitions distinct from
those in mathematics and the IEEE floating-point standard.

The C standard defines what it means by "negative zero" before
it starts using the term.  The Fortran standard assumes that
people will correctly guess what it means by the terms "positive
zero" and "negative zero," even though it does not define those
terms and gives them meanings different from the usual meanings.

Bob Corbett

<robert.corbett@sun.com> wrote:

> The Fortran standard is free to use the terms
> "positive zero" and "negative zero," but, to avoid confusion, it
> should point out that it is using definitions distinct from
> those in mathematics and the IEEE floating-point standard.

I'm not interested in debating how things should be written. I already
commented that I thought the text in question was written poorly. Usenet
is a particularly poor forum for crafting words. My interest in this
discussion was interpretation of the standard - not in grading its
writing.

I assure you that I have on occasion had quite nasty things to say about
some of the writing in it. So if this has just turned into a debate
about whether the writing is well done, don't expect me to defend it...
or to say anything further on that question.

I'll stick to interpretation instead of criticism. And my interpretation
of the word "negative zero" is that it refers to a zero that is
negative. This is a term used in the Fortran standard. (Whether it
should be or not is another question). Lacking any other definition, I
believe that it is to be interpreted as being the adjective "negative"
modifying the noun "zero".

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jul 15, 7:15 pm, robert.corb...@sun.com wrote:

> 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.

Just to make the example more concrete, consider the program

      PROGRAM MAIN
        WRITE (*, '(SP, F5.0)') -0.0
      END

Suppose that the value of -0.0 is consider to be both a zero value
and a negative value.  Section 10.6.1 of the Fortran 2003 standard
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.

Since -0.0 is considered a zero value, it is controlled by the
SP edit descriptor.  Section 10.7.4 states

     The SS, SP, and S edit descriptors temporarily change
     (9.4.1) the sign mode (9.4.5.14, 9.5.1.13) for the
     connection.  The edit descriptors SS, SP, and S set the
     sign mode corresponding to the SIGN= specifier values
     to SUPPRESS, PLUS, and PROCESSOR_DEFINED, respectively.

     The sign mode controls optional plus characters in
     numeric output fields.  When the sign mode is PLUS,
     the processor shall produce a plus sign in any position
     that normally contains an optional plus sign.

So. the output would normally contain an optional plus sign,
because the value of -0.0 is a zero value, but because the SP
edit descriptor is in effect, it shall include a plus sign.

Going back to Section 10.6.1, the standard continues

          The representation of a negative internal value
          in the field shall be prefixed with a minus sign.

So, if the value of -0.0 is considered to be both a zero
value and a negative value, the output value must include
both a minus sign and a plus sign.  Furthermore, I would say
that, based on the cited text, the minus sign must come first,
although I am less certain of that detail.

Bob Corbett

<robert.corbett@sun.com> wrote:

> So, if the value of -0.0 is considered to be both a zero
> value and a negative value, the output value must include
> both a minus sign and a plus sign.  Furthermore, I would say
> that, based on the cited text, the minus sign must come first,
> although I am less certain of that detail.

Feel free to implement it that way if you feel that to be the right
interpretation. :-)

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jul 16, 1:53 am, nos...@see.signature (Richard Maine) wrote:

> I'm not interested in debating how things should be written.

I am interested in how things should be written.  I think it
should be possible for someone to read the standard without
having to have the context of years of committee debates.
Although my experience with providing comments to J3 during
public reviews, including this very topic in the CD-1 review,
has been poor, I might again make the effort during the
Fortran 2008 public review.

Bob Corbett

On Jul 16, 2:01 am, nos...@see.signature (Richard Maine) wrote:
> <robert.corb...@sun.com> wrote:
> > So, if the value of -0.0 is considered to be both a zero
> > value and a negative value, the output value must include
> > both a minus sign and a plus sign.  Furthermore, I would say
> > that, based on the cited text, the minus sign must come first,
> > although I am less certain of that detail.
>
> Feel free to implement it that way if you feel that to be the right
> interpretation. :-)

You are creating a straw man.

Note the "if" in "if the value of -0.0 is considered to be both a
zero value and a negative value."  I do not believe it makes sense
for a minus zero to be interpreted as being a negative value.
Therefore, I do not interpret it that way.

Bob Corbett

On Jul 16, 2:01 am, nos...@see.signature (Richard Maine) wrote:
> <robert.corb...@sun.com> wrote:
> > So, if the value of -0.0 is considered to be both a zero
> > value and a negative value, the output value must include
> > both a minus sign and a plus sign.  Furthermore, I would say
> > that, based on the cited text, the minus sign must come first,
> > although I am less certain of that detail.
>
> Feel free to implement it that way if you feel that to be the right
> interpretation. :-)

Do you see a flaw in my argument, based on the standard
as written, that if the value -0.0 is considered to be both
a zero value and a negative value, then the program

      PROGRAM MAIN
        WRITE (*, '(SP, F5.0)') -0.0
      END

must write a value that is prefixed by both a plus sign and
a minus sign?  If so, what is that flaw?

Bob Corbett

robert.corbett@sun.com wrote:
> On Jul 15, 9:46 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 
>> "6.10.8 Use of words
>>
>> The word "shall" shall be used to express mandatory requirements.
>> The word "may" shall be used to express optional requirements.
>> Although the negative form of "shall" is "shall not", the negative
>> form of "may" is not "may not", but is "need not".
>> The use of "may not" shall be avoided."
> 
> It would seem that the opposite of "may" means the same thing
> as "may," but with a different emphasis.

Yep...

:)

--

In article <1184572698.921310.254810@m37g2000prh.googlegroups.com>,
 Terence <tbwright@cantv.net> wrote:

> If a real value very close to zero has to be expressed in a limited
> number of fractional digits, but these digits are all zeroes after the
> decimal point, then the appropriate sign should be prefixed to the
> values to indicate which side of absolute zero the values lies.

This is the basis of the problems.  There is a way to designate -0.0 
in this way (by using the sign bit), but there is no way to 
designate a +0.0 in this way that is distinct from the actual 0.0.

If, in hardware, there were a way to designate and differentiate 
-0.0, 0.0, and +0.0, then there would be no problems, everyone would 
know what the three values mean.

$.02 -Ron Shepard

On 2007-07-16 11:53:20 -0300, Ron Shepard 
<ron-shepard@NOSPAM.comcast.net> said:

> In article <1184572698.921310.254810@m37g2000prh.googlegroups.com>,
>  Terence <tbwright@cantv.net> wrote:
> 
>> If a real value very close to zero has to be expressed in a limited
>> number of fractional digits, but these digits are all zeroes after the
>> decimal point, then the appropriate sign should be prefixed to the
>> values to indicate which side of absolute zero the values lies.
> 
> This is the basis of the problems.  There is a way to designate -0.0
> in this way (by using the sign bit), but there is no way to
> designate a +0.0 in this way that is distinct from the actual 0.0.
> 
> If, in hardware, there were a way to designate and differentiate
> -0.0, 0.0, and +0.0, then there would be no problems, everyone would
> know what the three values mean.
> 
> $.02 -Ron Shepard

I once used a system where the output formatting provided 0.0 for an exact
zero and 0.000 (etc) for the case of all printing figures being zero.
The whole issue of zero vrs rounded to zero for display is awkward so
this was a convenience.

That was before the niceties of standards interfered with usefulness.
I also recall the bother with differing conversions by the compiler
and the runtime for inputs. So progress is not all bad. ;-)

When I care I now use the partial line (advance="no") machinery and
programming logic to achieve the same output formatting effect. In some
situations I even go the extra step of having exact zero output as all
blanks. I see a lot of missing and sparse data so I have gotten used to
my common idioms for this. Many others would undoubedly consider it
not worth the extra bother.

<robert.corbett@sun.com> wrote:

> On Jul 16, 1:53 am, nos...@see.signature (Richard Maine) wrote:
> 
> > I'm not interested in debating how things should be written.
> 
> I am interested in how things should be written. 

Me too. Speaking of the fine points of writing, I did not say that I was
uninterested in how things should be written. I said that I was not
interested in debating the subject. There is a distinction between those
statements. In particular, I am not interested in debating it here; I
think usenet a poor medium for such debates. I've occasionally debated
it at length in committee.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Ron Shepard wrote:
> In article <1184572698.921310.254810@m37g2000prh.googlegroups.com>,
> Terence <tbwright@cantv.net> wrote:
>
>> If a real value very close to zero has to be expressed in a limited
>> number of fractional digits, but these digits are all zeroes after
>> the decimal point, then the appropriate sign should be prefixed to
>> the values to indicate which side of absolute zero the values lies.
>
> This is the basis of the problems.  There is a way to designate -0.0
> in this way (by using the sign bit), but there is no way to
> designate a +0.0 in this way that is distinct from the actual 0.0.

Floating point is an approximation to reals.  Different floating
point implementations may have different interpretations of the
approximations they provide.  In IEEE floating point, there
are two different approximations to zero.  The concept of
*exactly* zero is *equally* represented by either of those
approximations (hence, the two compare equal to each other).

However, the two approximations differ in that they represent
different sets of values which intersect at one point: exactly zero.
So, the sign may carry important informaion.  Conversions to
other bases should preserve the sign.

> If, in hardware, there were a way to designate and differentiate
> -0.0, 0.0, and +0.0, then there would be no problems, everyone would
> know what the three values mean.

Actually, that description exemplifies the problem.  Most of
the IEEE operations specify very clearly what the sign of the
result should be.  Even when the magnitude (to the limit of the
representation) is zero, the sign bit usually preserves some
information.  The only exception is the result of an add or a
subtract.  Here the sign of the result is indeterminate (and the
IEEE standard allows the implementation to pick either one).
So, a signless zero would most naturally fit this result.  But
that means that, far from representing *exactly* zero, this
new value represents the union of the two approximations
represented by the signed zeros.  It's *less* exact.  (Indeed
it's *much* less exact since you didn't arrive at zero by
underflow, but by cancellation of the leading bits.  Such
concepts were intended to be addressed by interval arithmetic.)

So the real problem is that people tend to think that programs
can represent, manipulate, or produce metaphysically perfect
"exact" zeros in the first place.  Such things are fabulous
monsters.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> So the real problem is that people tend to think that programs
> can represent, manipulate, or produce metaphysically perfect
> "exact" zeros in the first place.  Such things are fabulous
> monsters.

I sure hope that a program can represent an exact zero.  I don't
really care how it does it, just as long as it can.  I'm well
aware of the dangers of performing a floating point comparison
between a variable and zero, but if I write:

  REAL X,Y
  LOGICAL L

  X = 0.0
  Y = 0.0
  L = X == Y

I sure want L to have the value .TRUE..  Of course, the same
would apply to any nonzero value as well.  Two variables
initialized to the same value should test as being the same.

But how about this case:

  REAL X,Y,Z
  LOGICAL L

  X = 1.0
  Y = 1.0
  Z = Y - X
  L = X == Y
  L = Z == 0.0

Presumably X and Y have the exact same internal representation,
regardless of how close an approximation it has to unity.  I
fully expect the first value of L to be .TRUE., but what about
the second value of L?  That's where I sure hope that a program
can represent an exact zero, whatever its internal representation
may be, such that the second value of L is also .TRUE..  After
all, when you difference two identical internal representations,
that's my idea of an exact zero, however it may be represented
internally.

The danger arises when you start manipulating a number.  For
example,

  REAL X,Y
  LOGICAL L

  X = 1.0
  Y = SQRT(X*X)
  L = X == Y

In this case, I no longer expect L to have the value .TRUE.,
even though mathematically it should be the case.  It probably
will be .TRUE. for certain selected values of X that can be
exactly represented, but for other values, expect .FALSE..

tholen@antispam.ham wrote:
> James Giles writes:
>
>> So the real problem is that people tend to think that programs
>> can represent, manipulate, or produce metaphysically perfect
>> "exact" zeros in the first place.  Such things are fabulous
>> monsters.
>
> I sure hope that a program can represent an exact zero.  [...]

It certainly can represent zero: as one of many possible values
of an approximation that includes zero.  If that's your definition
of representing an "exact" zero...  The point is that zero isn't the
*only* value associated with that approximation.  Floating point
programs represent, manipulate, and produce approximations.
Zero is no exception to that rule..  If you choose to believe that
such approximations *are* zero and *only* zero, you'll likely
have some problems.  As soon as your zero is in the hands of
the float implementation it becomes an approximation.

> The danger arises when you start manipulating a number.  For
> example,
>
>  REAL X,Y
>  LOGICAL L
>
>  X = 1.0
>  Y = SQRT(X*X)
>  L = X == Y
>
> In this case, I no longer expect L to have the value .TRUE.,
> even though mathematically it should be the case.  It probably
> will be .TRUE. for certain selected values of X that can be
> exactly represented, but for other values, expect .FALSE..

In the example given here, I would expect L to be .TRUE.  This
is because SQRT is part of the IEEE standard and has required
bounds on it's accuracy.  So is conversion from decimal.  So is
comparison.  With those three defined properties of the number
system I would expect L to be .TRUE. for a fairly large set of
literals you might substitute for 1.0 above (including 1.0 itself),
regardless of rounding mode.  In fact, even most non-IEEE
implementations can guarantee such behavior.

I would expect this because the mathematically exact calculation
(which is not what floating point does) is well within the required
tolerances of the approximations of the values and operations of
floating point.  The properties of the approximations are ironically
*exactly* defined as are the properties of the operations on those
approximations.  Except for order of evaluation (which is often
left to the language implementers discretion) floating point math
is deterministic and well defined.

Now a different (very similar) example with some other literal
than the set I identified above would not only result in L being
..FALSE., but the very rules of IEEE rounding would *require*
that L be false for those values (what set of literals that is depends
on what rounding mode you select).

Now all this ignores the Fortran standard itself which anomalously
(compared to most languages) allows the expression as written to
be evaluated by any "mathematically equivalent" expression instead.
In this case, it's perfectly reasonable for Fortran to notice that
SQRT(X*X) is the same as ABS(X).  (Whether it's allowed to
disregard the possibility of intermediate overflow is something
I've seen disputed.  I won't argue it here.)  So, you might get L
defined to .TRUE. for nearly all values of the literal in the
example.

All this is part of the reason that many (including me) recommend
that new computing students should recieve at least a semester
(and maybe more) of instruction on floating point.  Most people
get  almost no such instruction.  Indeed, among the ironic properties
of floating point is that although it can't do exact real arithmetic, it's
carefully designed rules can often allow you to do exact discrete
arithmetic.  I've often needed integers with more than 32 bits of
range and didn't want to pay the speed penalty of a multiple precision
integer package.  IEEE double carries 53 bit significands.  Careful
use of double allows correct integer arithmetic provided your
intermediate values don't exceed 2^53 in magnitude.  This is often
all I need.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

In article <1184580508.472710.36180@n60g2000hse.googlegroups.com>,
 <robert.corbett@sun.com> wrote:
>
>Do you see a flaw in my argument, based on the standard
>as written, that if the value -0.0 is considered to be both
>a zero value and a negative value, then the program
>
>      PROGRAM MAIN
>        WRITE (*, '(SP, F5.0)') -0.0
>      END
>
>must write a value that is prefixed by both a plus sign and
>a minus sign?  If so, what is that flaw?

http://developers.sun.com/sunstudio/articles/sign.html is instructive. 

Given the present state of the standard, which as we have seen allows 
Fortran experts to disagree, I'm not surprised that that program writes
  -0. with g95 and NAG f95, but
  +0. with gfortran, Sun f95 and Intel f95,

Would a Corbettian compiler write  -+0. or  +-0. ?

Would it help if a new edit descriptor in the S family were invented,
SZ perhaps, to make an IEEE-compliant processor write a zero real value 
with its sign? I take it that there is no real x such that ieee_class(x) 
is both ieee_negative_zero and ieee_positive_zero, and that if x==0.0 
then ieee_class(x) must be one of those values, so an IEEE real zero 
value always has a sign, which is one and only one of + and -.

-- John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

On Jul 16, 4:40 pm, har...@mcs.vuw.ac.nz (John Harper) wrote:
> In article <1184580508.472710.36...@n60g2000hse.googlegroups.com>,
>
>  <robert.corb...@sun.com> wrote:
>
> >Do you see a flaw in my argument, based on the standard
> >as written, that if the value -0.0 is considered to be both
> >a zero value and a negative value, then the program
>
> >      PROGRAM MAIN
> >        WRITE (*, '(SP, F5.0)') -0.0
> >      END
>
> >must write a value that is prefixed by both a plus sign and
> >a minus sign?  If so, what is that flaw?
>
> http://developers.sun.com/sunstudio/articles/sign.htmlis instructive.
>
> Given the present state of the standard, which as we have seen allows
> Fortran experts to disagree, I'm not surprised that that program writes
>   -0. with g95 and NAG f95, but
>   +0. with gfortran, Sun f95 and Intel f95,
>
> Would a Corbettian compiler write  -+0. or  +-0. ?

Neither.  As I pointed out in a previous posting, I do not
believe that the value of -0.0 is a negative value.  Therefore,
given the Fortran standard as it is currently written,  I
believe the output must be "  +0.".

> Would it help if a new edit descriptor in the S family were invented,
> SZ perhaps, to make an IEEE-compliant processor write a zero real value
> with its sign? I take it that there is no real x such that ieee_class(x)
> is both ieee_negative_zero and ieee_positive_zero, and that if x==0.0
> then ieee_class(x) must be one of those values, so an IEEE real zero
> value always has a sign, which is one and only one of + and -.

I still prefer my Z edit descriptor.

Bob Corbett

John Harper wrote:
....
> Would it help if a new edit descriptor in the S family were invented,
> SZ perhaps, to make an IEEE-compliant processor write a zero real
> value with its sign? I take it that there is no real x such that
> ieee_class(x) is both ieee_negative_zero and ieee_positive_zero, and
> that if x==0.0 then ieee_class(x) must be one of those values, so an
> IEEE real zero value always has a sign, which is one and only one of
> + and -.

By the time you could push through such a feature it would be long
past time for the committee to clarify that the sign of zero should
be retained on output.  I think that's already the rule, but it's admittedly
vague.  I don't like vague.  It should be clearly stated that the sign
of zero be retained.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

>>> So the real problem is that people tend to think that programs
>>> can represent, manipulate, or produce metaphysically perfect
>>> "exact" zeros in the first place.  Such things are fabulous
>>> monsters.

>> I sure hope that a program can represent an exact zero.  [...]

> It certainly can represent zero: as one of many possible values
> of an approximation that includes zero.  If that's your definition
> of representing an "exact" zero...

My definition of an "exact" zero is whatever internal representation
is used when two identical internal representations are differenced.

> The point is that zero isn't the
> *only* value associated with that approximation.  Floating point
> programs represent, manipulate, and produce approximations.
> Zero is no exception to that rule..  If you choose to believe that
> such approximations *are* zero and *only* zero, you'll likely
> have some problems.  As soon as your zero is in the hands of
> the float implementation it becomes an approximation.

A subset of floating point numbers can have an exact representation.
Zero should be a member of that subset.

>> The danger arises when you start manipulating a number.  For
>> example,
>>
>>  REAL X,Y
>>  LOGICAL L
>>
>>  X = 1.0
>>  Y = SQRT(X*X)
>>  L = X == Y
>>
>> In this case, I no longer expect L to have the value .TRUE.,
>> even though mathematically it should be the case.  It probably
>> will be .TRUE. for certain selected values of X that can be
>> exactly represented, but for other values, expect .FALSE..

> In the example given here, I would expect L to be .TRUE.  This
> is because SQRT is part of the IEEE standard and has required
> bounds on it's accuracy.  So is conversion from decimal.  So is
> comparison.  With those three defined properties of the number
> system I would expect L to be .TRUE. for a fairly large set of
> literals you might substitute for 1.0 above (including 1.0 itself),
> regardless of rounding mode.  In fact, even most non-IEEE
> implementations can guarantee such behavior.

What about the reverse case:

  Y = (SQRT(X))**2

> I would expect this because the mathematically exact calculation
> (which is not what floating point does) is well within the required
> tolerances of the approximations of the values and operations of
> floating point.  The properties of the approximations are ironically
> *exactly* defined as are the properties of the operations on those
> approximations.  Except for order of evaluation (which is often
> left to the language implementers discretion) floating point math
> is deterministic and well defined.

But subject to approximation.

> Now a different (very similar) example with some other literal
> than the set I identified above would not only result in L being
> ..FALSE., but the very rules of IEEE rounding would *require*
> that L be false for those values (what set of literals that is depends
> on what rounding mode you select).
>
> Now all this ignores the Fortran standard itself which anomalously
> (compared to most languages) allows the expression as written to
> be evaluated by any "mathematically equivalent" expression instead.
> In this case, it's perfectly reasonable for Fortran to notice that
> SQRT(X*X) is the same as ABS(X).  (Whether it's allowed to
> disregard the possibility of intermediate overflow is something
> I've seen disputed.  I won't argue it here.)  So, you might get L
> defined to .TRUE. for nearly all values of the literal in the
> example.

In which case I didn't choose the best example for the point I was
trying to make.  My point is that after manipulation, one should not
expect a number to have the same exact internal representation, even
if algebraically the number should be unchanged.  There may be
special cases where the compiler may determine that no manipulation
is necessary, thus the internal representation should stay the same.
For purposes of my example, let's ignore those cases.  But we're
drifting away from the main point, which is about my concept of an
"exact" zero, as I defined above.

> All this is part of the reason that many (including me) recommend
> that new computing students should recieve at least a semester
> (and maybe more) of instruction on floating point.  Most people
> get  almost no such instruction.  Indeed, among the ironic properties
> of floating point is that although it can't do exact real arithmetic, it's
> carefully designed rules can often allow you to do exact discrete
> arithmetic.  I've often needed integers with more than 32 bits of
> range and didn't want to pay the speed penalty of a multiple precision
> integer package.  IEEE double carries 53 bit significands.  Careful
> use of double allows correct integer arithmetic provided your
> intermediate values don't exceed 2^53 in magnitude.  This is often
> all I need.

Actually, I'm dealing with an interesting floating point case right
now, but have been debating whether to bring it up for discussion in
this newsgroup.

tholen@antispam.ham wrote:
> James Giles writes:
....
>> It certainly can represent zero: as one of many possible values
>> of an approximation that includes zero.  If that's your definition
>> of representing an "exact" zero...
>
> My definition of an "exact" zero is whatever internal representation
> is used when two identical internal representations are differenced.

Ok, but there are two such numbers.  Minus zero and plus zero are
both allowed as results of that operation.  Which of those is "exact"
zero?   They both compare equal to plus zero (they both compare
equal to minus zero).  This all disregards the known property that
differences of nearly identical (or, in this case, identical) values
leaves little or no significance in the result (at least assuming the
numbers being subtracted are the result of prior calculation).
Again I point out that things like interval arithmetic were indended
to address this property.

....
>>>
>>>  REAL X,Y
>>>  LOGICAL L
>>>
>>>  X = 1.0
>>>  Y = SQRT(X*X)
>>>  L = X == Y
....
> What about the reverse case:
>
>  Y = (SQRT(X))**2


The set of values for which L will be .TRUE. for that changed
expression is different, but there are numbers (1.0 included)
for which I would expect .TRUE. regardless of rounding mode.
The set is somewhat smaller than for the original example.
And of course Fortran can still see the identity that SQRT(X)**2
is X.  (Some people have disputed whether Fortran is permitted
to disregard the fact that negative values of X are invalid in
the original expression.  I won't debate it here.)

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

I should have said (but nobody caught the typos) that :-
(0.0 -1/x) for all positive values of x yields a negative real value.
(0.0 +1/x) for all positive values of x yields a positive real value.
The functions don't intersect.

Values in Physics can run from around 10**-35 to 10**42 which is why
knowing if something is REALLY negative or REALLY positive (at the
samll end) can sometimes de quite important.

On Jul 15, 7:15 pm, robert.corb...@sun.com wrote:

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

I was mistaken.  The interpretation request for this issue is
F03/0080.  There has been progress on it.  The discussion
section of the proposed interpretation shows a good
understanding of the issue.  The proposed edits solve half of
the problem.  I shall work with Sun's representative to J3 to
deal with the remaining part of the problem.

Bob Corbett

In article <1184736823.606603.120930@g12g2000prg.googlegroups.com>,
 <robert.corbett@sun.com> wrote:
>On Jul 15, 7:15 pm, robert.corb...@sun.com wrote:
>
>> There is an official interpretation request on this issue, but
>> J3 has made no progress on it.
>
>I was mistaken.  The interpretation request for this issue is
>F03/0080.  There has been progress on it.  The discussion
>section of the proposed interpretation shows a good
>understanding of the issue.  The proposed edits solve half of
>the problem.  I shall work with Sun's representative to J3 to
>deal with the remaining part of the problem.
>
>Bob Corbett

I was mistaken in thinking I was mistaken.  The discussion
and proposed edits I found were added to the interpretation
request by Sun's representative to J3 when it was submitted.
There is no sign that J3 has considered the request.  I hope
J3 considers the interpretation request in time for
Fortran 2008.  I would prefer to have this matter settled
in the next revision of the standard.

Bob Corbett

Robert Corbett wrote:

(snip)

> I was mistaken in thinking I was mistaken.  The discussion
> and proposed edits I found were added to the interpretation
> request by Sun's representative to J3 when it was submitted.
> There is no sign that J3 has considered the request.  I hope
> J3 considers the interpretation request in time for
> Fortran 2008.  I would prefer to have this matter settled
> in the next revision of the standard.

Are you also interested in different representations for
a true zero (of any sign) and small but non-zero values?

I previously wrote about an implementation (from Fortran 66 days)
that printed +0.0 for negative zero, and I believe 0.0 for positive
zero even when the Format specified more than one digit after
the decimal point.  I think someone wrote that this was legal
Fortran 66, but not in later standards.

-- glen

James Giles writes:

> ....

>>> It certainly can represent zero: as one of many possible values
>>> of an approximation that includes zero.  If that's your definition
>>> of representing an "exact" zero...

>> My definition of an "exact" zero is whatever internal representation
>> is used when two identical internal representations are differenced.

> Ok, but there are two such numbers.  Minus zero and plus zero are
> both allowed as results of that operation.

Why not three?  Minus zero, plus zero, and blank zero?

> Which of those is "exact" zero?

Maybe I've misunderstood the earlier discussion, but I thought that
minus zero applied only to cases where the actual numerical value
was in fact negative, but the chosen display format was insufficient
to show any significant digits, therefore the number would be displayed
as all zeros, with the question being whether to display the minus sign
or not.  For example, should the value -1.2E-5, when displayed with the
format edit descriptor F4.1, be -0.0 or  0.0?

As far as I am concerned, there is only one exact zero, not two, and
not three, and there should be no sign associated with an exact zero.

> They both compare equal to plus zero (they both compare
> equal to minus zero).  This all disregards the known property that
> differences of nearly identical (or, in this case, identical) values
> leaves little or no significance in the result (at least assuming the
> numbers being subtracted are the result of prior calculation).
> Again I point out that things like interval arithmetic were indended
> to address this property.

I am unfamiliar with the concept of interval arithmetic.

> ....

>>>>
>>>>  REAL X,Y
>>>>  LOGICAL L
>>>>
>>>>  X = 1.0
>>>>  Y = SQRT(X*X)
>>>>  L = X == Y

> ....

>> What about the reverse case:
>>
>>  Y = (SQRT(X))**2

> The set of values for which L will be .TRUE. for that changed
> expression is different, but there are numbers (1.0 included)
> for which I would expect .TRUE. regardless of rounding mode.
> The set is somewhat smaller than for the original example.
> And of course Fortran can still see the identity that SQRT(X)**2
> is X.  (Some people have disputed whether Fortran is permitted
> to disregard the fact that negative values of X are invalid in
> the original expression.  I won't debate it here.)

Suppose Y had been declared as COMPLEX?

tholen@antispam.ham wrote:

> James Giles writes:

(snip)

>>Ok, but there are two such numbers.  Minus zero and plus zero are
>>both allowed as results of that operation.

> Why not three?  Minus zero, plus zero, and blank zero?

>>Which of those is "exact" zero?

> Maybe I've misunderstood the earlier discussion, but I thought that
> minus zero applied only to cases where the actual numerical value
> was in fact negative, but the chosen display format was insufficient

I believe the discussion is for an exact zero with a sign bit of '1'.

The case you mention should is also important, but different.

> to show any significant digits, therefore the number would be displayed
> as all zeros, with the question being whether to display the minus sign
> or not.  For example, should the value -1.2E-5, when displayed with the
> format edit descriptor F4.1, be -0.0 or  0.0?

> As far as I am concerned, there is only one exact zero, not two, and
> not three, and there should be no sign associated with an exact zero.

I haven't read it recently, but I believe the the IEEE floating
point standard has some requirements regarding exact zero with a
negative sign.  Some of those requirements conflicted with earlier
Fortran standards, such that the standard was changed to allow for
them.

> I am unfamiliar with the concept of interval arithmetic.

Similar to the value and uncertainty used in physics, among others,
a variable might have a lower and upper limit instead of a single
value.

Related to the question of zero and interval arithmetic, the IBM
stretch had a feature that would allow one to select whether
zero or one bits were shifted in during post normalization,
especially after addition and subtraction.  As I understand it,
a program could be run both ways and any difference in the results
indicated possible significance loss. If I understand it, subtraction
of equal values would not result in zero.  I don't know of this feature
on any machines since then.  (S/360 has a significance exception for
the subtraction of equal values.  It is normally disabled.)

-- glen

tholen@antispam.ham wrote:
> James Giles writes:
....
> Maybe I've misunderstood the earlier discussion, but I thought that
> minus zero applied only to cases where the actual numerical value
> was in fact negative, but the chosen display format was insufficient
> to show any significant digits, therefore the number would be
> displayed as all zeros, with the question being whether to display
> the minus sign or not.  For example, should the value -1.2E-5, when
> displayed with the format edit descriptor F4.1, be -0.0 or  0.0?

That's easy, the Fortran standard says that a negative value should
have a minus sign output.  The earlier discussion was more concerned
over whether an internal value was negative or not, when its magnitude
was zero but it had a set sign bit.  The rule should be more clearly
stated in the standard: if the sign bit is set the output should begin
(after any padding blanks) with a minus sign.  That's independent of
the magnitude (infact, I think that should be the rule even if the
number turns out to be NaN).

> As far as I am concerned, there is only one exact zero, not two, and
> not three, and there should be no sign associated with an exact zero.

And, if you're simulating genuine real numbers with your floating
point REAL data type, you'll *never* see something you're sure
is an exact zero.

Suppose you have a record of temperatures recorded at some
observing site and you go through generating a first-difference
(an approximation to a derivative).  Well, the thermometer reports
to a tenth of a degree.  Suppose two consecutive times show a
value of 15 degrees.  That means each value is actually somewhere
between 14.95 and 15.05 degrees and whatever true temp occurred
was rounded to just 15.0 degrees.  The float difference of those two
measurements will have a magnitude of zero.  But, it's pretty clear
that the temps at the two times were almost certainly more different
than the ~10^(-39) precision of floating point!  That zero difference
is hardly *exact*  (in fact, the correct answer is in the interval from
-0.1 through 0.1, somewhere).  The sign printed with a zero arising
from such a calculation is meaningless, why do you care which is
printed?

In using float to simulate continuous real arithmetic, zeros
can arise a number of ways.  They reduce to two categories:
1) underflow, where the sign bit still carries useful (maybe
decisive) information; 2) result of discrete approximation
(like the above difference) where the sign bit means nothing
and a good programmer knows it.  There are no third cases,
that is, where it's actually *important* to supress the sign.

Now if you are using floating point to do some kind of discrete
arithmetic rather than as a surrogate for continuous reals, the
sign bit of zero may or may not be important (usually not).
However, I can still see no reason for the implementation
to supress it.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

I found it necessary (way long ago) to write an editing subroutine for
report writing, to output real values within a string of a given
length and number of decimal digits. For the reasons under discussion
I put a minus sign prefix if the original value was negative to any
precision at at all, zero being 0.0 and other positive values shown
without sign to the full truncated length.
I still use the same routine.

On Jul 18, 2:34 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Robert Corbett wrote:
>
> (snip)
>
> > I was mistaken in thinking I was mistaken.  The discussion
> > and proposed edits I found were added to the interpretation
> > request by Sun's representative to J3 when it was submitted.
> > There is no sign that J3 has considered the request.  I hope
> > J3 considers the interpretation request in time for
> > Fortran 2008.  I would prefer to have this matter settled
> > in the next revision of the standard.
>
> Are you also interested in different representations for
> a true zero (of any sign) and small but non-zero values?
>
> I previously wrote about an implementation (from Fortran 66 days)
> that printed +0.0 for negative zero, and I believe 0.0 for positive
> zero even when the Format specified more than one digit after
> the decimal point.  I think someone wrote that this was legal
> Fortran 66, but not in later standards.

In an earlier posting, I proposed adding three new edit descriptors,
ZP, ZS, and ZU.  The edit descriptor ZU together with the edit
descriptor SP allows the user to specify a format that will
distinguish zero values from non-zero values close to zero under
an F edit descriptor.  The ZU edit descriptor suppresses a sign
being printed for zero, regardless of the sign control specified.
For example,

      WRITE (*, '(SP, ZU, (F5.2))') -1E-10, -0.0, +0.0, +1E10

would write

-0.00
 0.00
 0.00
+0.00

Bob Corbett

robert.corbett@sun.com wrote:

> On Jul 18, 2:34 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 
>>Robert Corbett wrote:
>>
>>(snip)
>>
>>
>>>I was mistaken in thinking I was mistaken.  The discussion
>>>and proposed edits I found were added to the interpretation
>>>request by Sun's representative to J3 when it was submitted.
>>>There is no sign that J3 has considered the request.  I hope
>>>J3 considers the interpretation request in time for
>>>Fortran 2008.  I would prefer to have this matter settled
>>>in the next revision of the standard.
>>
>>Are you also interested in different representations for
>>a true zero (of any sign) and small but non-zero values?
>>
>>I previously wrote about an implementation (from Fortran 66 days)
>>that printed +0.0 for negative zero, and I believe 0.0 for positive
>>zero even when the Format specified more than one digit after
>>the decimal point.  I think someone wrote that this was legal
>>Fortran 66, but not in later standards.
> 
> 
> In an earlier posting, I proposed adding three new edit descriptors,
> ZP, ZS, and ZU.  The edit descriptor ZU together with the edit
> descriptor SP allows the user to specify a format that will
> distinguish zero values from non-zero values close to zero under
> an F edit descriptor.  The ZU edit descriptor suppresses a sign
> being printed for zero, regardless of the sign control specified.
> For example,
> 
>       WRITE (*, '(SP, ZU, (F5.2))') -1E-10, -0.0, +0.0, +1E10
> 
> would write
> 
> -0.00
>  0.00
>  0.00
> +0.00
> 
> Bob Corbett
> 
I like that.  I'd prefer something different though, maybe <0.00 or 
 >0.00.  Mostly because I don't believe in the concept of negative (or 
positive) zero.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

On Jul 19, 7:09 pm, robert.corb...@sun.com wrote:

> In an earlier posting, I proposed adding three new edit descriptors,
> ZP, ZS, and ZU.  The edit descriptor ZU together with the edit
> descriptor SP allows the user to specify a format that will
> distinguish zero values from non-zero values close to zero under
> an F edit descriptor.  The ZU edit descriptor suppresses a sign
> being printed for zero, regardless of the sign control specified.
> For example,
>
>       WRITE (*, '(SP, ZU, (F5.2))') -1E-10, -0.0, +0.0, +1E10
                                                          ^^^^^

Ooops.  Should have been +1E-10.
>
> would write
>
> -0.00
>  0.00
>  0.00
> +0.00

Bob Corbett

On Jul 16, 5:54 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:

> By the time you could push through such a feature it would be long
> past time for the committee to clarify that the sign of zero should
> be retained on output.

I don't know.  J3 seems more inclined to add new features than to work
on interpretations.  Even when they do work on interpretations, the
signs are bad for the interpretation regarding this issue.  I note
that the committee has skipped over this interpretation.  I would not
be surprised if they don't deal with it in time for Fortran 1008.

> I think that's already the rule, but it's admittedly
> vague.  I don't like vague.  It should be clearly stated that
> the sign of zero be retained.

The rule that would require the external representation of a zero
value that is a negative zero to be prefixed with a minus sign might
be vague, but the part of the standard that requires that the external
representation of a zero value must be prefixed with a plus sign when
the sign control is POSITIVE is not vague.

Bob Corbett
i

robert.corbett@sun.com wrote:
> On Jul 16, 5:54 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
....
>> I think that's already the rule, but it's admittedly
>> vague.  I don't like vague.  It should be clearly stated that
>> the sign of zero be retained.
>
> The rule that would require the external representation of a zero
> value that is a negative zero to be prefixed with a minus sign might
> be vague, but the part of the standard that requires that the external
> representation of a zero value must be prefixed with a plus sign when
> the sign control is POSITIVE is not vague.

Yes a non-negative zero is sometimes required to be prefixed
with a plus sign, just like all non-negative values when some
options are in effect.  And there are places in the the standard
left over from the bad old days where they fail to distinguish
cases where zeros have signs.  They still need to fix those.
The fix *isn't* to add a bunch of options to supress correct
display of useful numerical information - like the sign of
a number.

An internal value with a set sign bit should never be
misrepresented by supressing the sign, regardless of its
magnitude.  I held this position even when the standard
still said negative signs on non-zero (but small magnitude)
values had to be supressed on output if all the digits were
zero.  That was a really dumb rule.  No user agreed with
it (most were unaware of it until I pointer it out to them
while asking their opinion of that "feature" - and they
were mostly incensed that the language of preference for
numerical work would have such a stupid rule).

In those days I recommended an option (that would be the
default) to do the rignt thing numerically regardless of the
numerically incorrect Fortran standard.  That's what my
I/O library did.  As far as I know, no one but me ever even
tested turning off that option (for Fortran compliance).  People
that want to do meaningful numerical work didn't want the sign
bit misrepresented on output.  They still don't.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

> I am unfamiliar with the concept of interval arithmetic.

In all seriousness: If you are using floating-point arithmetic at all, not 
knowing interval arithmetic is a serious gap in education. The English 
Wikipedia only has a short section in a larger article on intervals, but 
points you to the corresponding German article that even has a nice worked 
example. As a motivation, it uses measurement error of physical properties, 
but of course the intrinsic properties of floating-point numbers apply in just 
the same way.

	Jan

James Giles writes:

> ....

>> Maybe I've misunderstood the earlier discussion, but I thought that
>> minus zero applied only to cases where the actual numerical value
>> was in fact negative, but the chosen display format was insufficient
>> to show any significant digits, therefore the number would be
>> displayed as all zeros, with the question being whether to display
>> the minus sign or not.  For example, should the value -1.2E-5, when
>> displayed with the format edit descriptor F4.1, be -0.0 or  0.0?

> That's easy, the Fortran standard says that a negative value should
> have a minus sign output.  The earlier discussion was more concerned
> over whether an internal value was negative or not, when its magnitude
> was zero but it had a set sign bit.  The rule should be more clearly
> stated in the standard: if the sign bit is set the output should begin
> (after any padding blanks) with a minus sign.  That's independent of
> the magnitude (infact, I think that should be the rule even if the
> number turns out to be NaN).

Why should the sign bit be set if the magnitude is zero?

>> As far as I am concerned, there is only one exact zero, not two, and
>> not three, and there should be no sign associated with an exact zero.

> And, if you're simulating genuine real numbers with your floating
> point REAL data type, you'll *never* see something you're sure
> is an exact zero.

Why not?  Suppose I difference two real numbers that have the exact
same internal representation.

> Suppose you have a record of temperatures recorded at some
> observing site and you go through generating a first-difference
> (an approximation to a derivative).  Well, the thermometer reports
> to a tenth of a degree.  Suppose two consecutive times show a
> value of 15 degrees.  That means each value is actually somewhere
> between 14.95 and 15.05 degrees and whatever true temp occurred
> was rounded to just 15.0 degrees.  The float difference of those two
> measurements will have a magnitude of zero.  But, it's pretty clear
> that the temps at the two times were almost certainly more different
> than the ~10^(-39) precision of floating point!  That zero difference
> is hardly *exact*  (in fact, the correct answer is in the interval from
> -0.1 through 0.1, somewhere).  The sign printed with a zero arising
> from such a calculation is meaningless, why do you care which is
> printed?

You're assuming that I would want one or the other printed.  In such
a case, I would be content to have no sign.  It's up to the user to
properly interpret the results of a calculation.

> In using float to simulate continuous real arithmetic, zeros
> can arise a number of ways.  They reduce to two categories:
> 1) underflow, where the sign bit still carries useful (maybe
> decisive) information; 2) result of discrete approximation
> (like the above difference) where the sign bit means nothing
> and a good programmer knows it.  There are no third cases,
> that is, where it's actually *important* to supress the sign.

If the sign bit carries decisive information, then it's important
for the correct sign to be displayed.  In your temperature example
above, you noted that the correct answer could be either positive
or negative, so there is no way for the processor to know which is
the correct sign, thus I would argue it's important to suppress the
sign.

> Now if you are using floating point to do some kind of discrete
> arithmetic rather than as a surrogate for continuous reals, the
> sign bit of zero may or may not be important (usually not).
> However, I can still see no reason for the implementation
> to supress it.

Consider your temperature example.  The sign could be misleading
if not suppressed.

jvorbrueggen@not-mediasec.de writes:

>> I am unfamiliar with the concept of interval arithmetic.

> In all seriousness: If you are using floating-point arithmetic at all, not 
> knowing interval arithmetic is a serious gap in education.

I disagree.

> The English 
> Wikipedia only has a short section in a larger article on intervals, but 
> points you to the corresponding German article that even has a nice worked 
> example. As a motivation, it uses measurement error of physical properties, 
> but of course the intrinsic properties of floating-point numbers apply in just 
> the same way.

For that I use propagation of error techniques.  Sounds like a different
path to the same end result, hence my disagreement above.

Doesn't sound like interval arithmetic is necessarily going to provide
what a physical scientist needs.  Consider the following simplified
example.  Suppose you want to know the distance from A to C, but what
you have are measurements of the distance from A to B, and from B to C.
Suppose the positions of A and C are extremely well known, but the
position of B is very poorly known.  Your measurement of the distance
from A to B will have a large uncertainty associated with it.  Ditto for
your measurement of the distance from B to C.  Computationally, the
distance from A to C is simply the sum of the distances between A and B,
and between B and C.  You might erroneously propagate the error using

   dz**2 = dx**2 + dy**2

for the case

   z = x + y

the error being due to the fact that x and y are anticorrelated.  How is
interval arithmetic going to know that?

> For that I use propagation of error techniques.  Sounds like a different
> path to the same end result, hence my disagreement above.

That is appropriate for any knowledge about the system you might have. 
Interval arithemtic reflects the fact that the computational system you are 
using - floating-point numbers instead of mathematical real numbers - 
introduces an additional and seperate (but conceptually similar) 
uncertainty/error into the computation.

> How is interval arithmetic going to know that?

It doesn't. In many cases - and that has been a major criticism - it produces 
worst-case results, such that the result might be [-INF, +INF], which we 
already knew beforehand. That doesn't obviate the need to take the errors 
introduced by the finite nature of floating-point numbers into account when 
interpreting a computation's results.

	Jan

jvorbrueggen@not-mediasec.de writes:

>> For that I use propagation of error techniques.  Sounds like a different
>> path to the same end result, hence my disagreement above.

> That is appropriate for any knowledge about the system you might have. 
> Interval arithemtic reflects the fact that the computational system you are 
> using - floating-point numbers instead of mathematical real numbers - 
> introduces an additional and seperate (but conceptually similar) 
> uncertainty/error into the computation.

Yes, but usually the computational error is smaller than other sources
of error.  When they're not, higher precision is necessary.  I rarely
use REAL*4 for the physical problems I deal with.  REAL*8 is almost
always adequate.

Where problems can arise is when the computational error accumulates,
such as in long term numerical integration of the motions of a system
of bodies.  Specialized techniques have to be used for thse.

>> How is interval arithmetic going to know that?

> It doesn't. In many cases - and that has been a major criticism - it produces 
> worst-case results, such that the result might be [-INF, +INF], which we 
> already knew beforehand. That doesn't obviate the need to take the errors 
> introduced by the finite nature of floating-point numbers into account when 
> interpreting a computation's results.

Depends on whether the quantization noise of the machine is large enough
relative to other sources of uncertainty.

On Jul 19, 11:25 pm, "James Giles" <jamesgi...@worldnet.att.net>
wrote:

> An internal value with a set sign bit should never be
> misrepresented by supressing the sign, regardless of its
> magnitude.  I held this position even when the standard
> still said negative signs on non-zero (but small magnitude)
> values had to be supressed on output if all the digits were
> zero.  That was a really dumb rule.  No user agreed with
> it (most were unaware of it until I pointer it out to them
> while asking their opinion of that "feature" - and they
> were mostly incensed that the language of preference for
> numerical work would have such a stupid rule).

The standard changed from prohibiting the minus sign for
negative values near zero that would printed as zero to
requiring the minus sign for such values in Fortran 95.
When Sun implemented that change, we did get some complaints
from users.  I suspect that if the rule had always been to
include the minus sign, there would not have been any
complaints, but the change in behavior did result in
complaints.

Bob Corbett

tholen@antispam.ham wrote:
> James Giles writes:
....
> Why should the sign bit be set if the magnitude is zero?

It's often decisive information.  It's up to th euser to know if it
matters - it's *NOT* up to the implementation to arbitrarily decide
for the user.  If it worries you, be content that I don't know any
implementations that set the sign bit for zeros that result from
sums or differences.  The IEEE standard allows either sign
in such a case.  For underflow the sign almost always carries
useful information.  The implementation should never supress
it.

>> And, if you're simulating genuine real numbers with your floating
>> point REAL data type, you'll *never* see something you're sure
>> is an exact zero.
>
> Why not?  Suppose I difference two real numbers that have the exact
> same internal representation.

Then the *actual* difference is approximately the same magnitude
as the error in the least accurately calculated of the two operands.
For nearly all calculations that's a lots bigger than zero.

>> Suppose you have a record of temperatures recorded at some
>> observing site and you go through generating a first-difference
>> (an approximation to a derivative).  Well, the thermometer reports
>> to a tenth of a degree.  Suppose two consecutive times show a
>> value of 15 degrees.  That means each value is actually somewhere
>> between 14.95 and 15.05 degrees and whatever true temp occurred
>> was rounded to just 15.0 degrees.  The float difference of those two
>> measurements will have a magnitude of zero.  But, it's pretty clear
>> that the temps at the two times were almost certainly more different
>> than the ~10^(-39) precision of floating point!  That zero difference
>> is hardly *exact*  (in fact, the correct answer is in the interval
>> from -0.1 through 0.1, somewhere).  The sign printed with a zero
>> arising from such a calculation is meaningless, why do you care
>> which is printed?
>
> You're assuming that I would want one or the other printed.  In such
> a case, I would be content to have no sign.  It's up to the user to
> properly interpret the results of a calculation.

And it's not up to the implementation to make that decision for
him(her).  If it's up to the user, leave the sign there and let
the user decide.  Never lie to the user.

> If the sign bit carries decisive information, then it's important
> for the correct sign to be displayed.  In your temperature example
> above, you noted that the correct answer could be either positive
> or negative, so there is no way for the processor to know which is
> the correct sign, thus I would argue it's important to suppress the
> sign.

But, an absent sign *means* positive zero!  Supressing it has no
advantages.  It helps no one.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

robert.corbett@sun.com wrote:
> On Jul 19, 11:25 pm, "James Giles" <jamesgi...@worldnet.att.net>
> wrote:
>
>> An internal value with a set sign bit should never be
>> misrepresented by supressing the sign, regardless of its
>> magnitude.  I held this position even when the standard
>> still said negative signs on non-zero (but small magnitude)
>> values had to be supressed on output if all the digits were
>> zero.  That was a really dumb rule.  No user agreed with
>> it (most were unaware of it until I pointer it out to them
>> while asking their opinion of that "feature" - and they
>> were mostly incensed that the language of preference for
>> numerical work would have such a stupid rule).
>
> The standard changed from prohibiting the minus sign for
> negative values near zero that would printed as zero to
> requiring the minus sign for such values in Fortran 95.
> When Sun implemented that change, we did get some complaints
> from users.  I suspect that if the rule had always been to
> include the minus sign, there would not have been any
> complaints, but the change in behavior did result in
> complaints.


Some users have test cases that they run for each new compiler.
They expect *identical* results or they assume the compiler
introduced new bugs.  (I know, I used to run such tests when
I did site maintenance on Cray compilers at the lab.)  If the
change has a valid explanation, the new behavior becomes
the new target for future such tests.  In this case, I suspect
they decided the new behavior was superior.  If you had
asked them before the change, I suspect they wouldn't have
been aware of the old rule in the first place and would
have requested the change with or without the standard's
approval.  That's the answer I always got (and I was working
on an f77 implementation at the time).

The implementation should never lie to the user.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

On 2007-07-20 04:51:21 -0300, tholen@antispam.ham said:

> James Giles writes:
> 
>> ....
> 
>>> Maybe I've misunderstood the earlier discussion, but I thought that
>>> minus zero applied only to cases where the actual numerical value
>>> was in fact negative, but the chosen display format was insufficient
>>> to show any significant digits, therefore the number would be
>>> displayed as all zeros, with the question being whether to display
>>> the minus sign or not.  For example, should the value -1.2E-5, when
>>> displayed with the format edit descriptor F4.1, be -0.0 or  0.0?
> 
>> That's easy, the Fortran standard says that a negative value should
>> have a minus sign output.  The earlier discussion was more concerned
>> over whether an internal value was negative or not, when its magnitude
>> was zero but it had a set sign bit.  The rule should be more clearly
>> stated in the standard: if the sign bit is set the output should begin
>> (after any padding blanks) with a minus sign.  That's independent of
>> the magnitude (infact, I think that should be the rule even if the
>> number turns out to be NaN).
> 
> Why should the sign bit be set if the magnitude is zero?

Two analogies:

1. Font hinting is something that is not true in some restricted and narrow
   sense but it sure makes a lot of things a lot smoother.

2. Extended reals are a valid mathematical system that you may not be familiar
   with that shares many properties with the reals and also permits various
   additional operations to proceed gracefully. (There are even some rather
   "wild" systems that mimic what you would think of as ordinary arithmetic
   but that lead to a lot of interesting (at least to those who study them)
   mathematics.)

Signed zeros may not be what you are used to or were taught in an earlier
mathematics course but they do make a lot of things proceed more gracefully
if used according to their intended rules. You can view the signed zeros as
hints of their history which can be important in many analytic applications
or as a similar formal system with only a few rules changed.

The usual rule of "if you don't like it then don't use it" applies with
the additional comment that you may have to ignore some negaive signs
on a few zeros supplied by others.

>>> As far as I am concerned, there is only one exact zero, not two, and
>>> not three, and there should be no sign associated with an exact zero.
> 
>> And, if you're simulating genuine real numbers with your floating
>> point REAL data type, you'll *never* see something you're sure
>> is an exact zero.
> 
> Why not?  Suppose I difference two real numbers that have the exact
> same internal representation.
> 
>> Suppose you have a record of temperatures recorded at some
>> observing site and you go through generating a first-difference
>> (an approximation to a derivative).  Well, the thermometer reports
>> to a tenth of a degree.  Suppose two consecutive times show a
>> value of 15 degrees.  That means each value is actually somewhere
>> between 14.95 and 15.05 degrees and whatever true temp occurred
>> was rounded to just 15.0 degrees.  The float difference of those two
>> measurements will have a magnitude of zero.  But, it's pretty clear
>> that the temps at the two times were almost certainly more different
>> than the ~10^(-39) precision of floating point!  That zero difference
>> is hardly *exact*  (in fact, the correct answer is in the interval from
>> -0.1 through 0.1, somewhere).  The sign printed with a zero arising
>> from such a calculation is meaningless, why do you care which is
>> printed?
> 
> You're assuming that I would want one or the other printed.  In such
> a case, I would be content to have no sign.  It's up to the user to
> properly interpret the results of a calculation.
> 
>> In using float to simulate continuous real arithmetic, zeros
>> can arise a number of ways.  They reduce to two categories:
>> 1) underflow, where the sign bit still carries useful (maybe
>> decisive) information; 2) result of discrete approximation
>> (like the above difference) where the sign bit means nothing
>> and a good programmer knows it.  There are no third cases,
>> that is, where it's actually *important* to supress the sign.
> 
> If the sign bit carries decisive information, then it's important
> for the correct sign to be displayed.  In your temperature example
> above, you noted that the correct answer could be either positive
> or negative, so there is no way for the processor to know which is
> the correct sign, thus I would argue it's important to suppress the
> sign.
> 
>> Now if you are using floating point to do some kind of discrete
>> arithmetic rather than as a surrogate for continuous reals, the
>> sign bit of zero may or may not be important (usually not).
>> However, I can still see no reason for the implementation
>> to supress it.
> 
> Consider your temperature example.  The sign could be misleading
> if not suppressed.

tholen@antispam.ham wrote:

> If the sign bit carries decisive information, then it's important
> for the correct sign to be displayed.

In IEEE complex arithmetic, signed zeros are used to decide which
side of a branch cut to use for functions that have one.  So yes,
it can make a difference.


-- 
pa at panix dot com

Gordon Sande wrote:

(snip)

> Signed zeros may not be what you are used to or were taught in an earlier
> mathematics course but they do make a lot of things proceed more gracefully
> if used according to their intended rules. You can view the signed zeros as
> hints of their history which can be important in many analytic applications
> or as a similar formal system with only a few rules changed.

Signed zeros are similar to what is used for limits in calculus,
usually written with the sign after the zero.

lim x->0+ or lim x->0- meaning the limit from the positive or negative
side of zero.

-- glen

> Yes, but usually the computational error is smaller than other sources
> of error.  When they're not, higher precision is necessary.  I rarely
> use REAL*4 for the physical problems I deal with.  REAL*8 is almost
> always adequate.

But why would REAL*4, with its LSB relative error of about 10^-7, not be 
adequate for most physical computation? I sure never measured anything to even 
remotely that precision...

	Jan

>Zero should be a member of that subset.

"should" should be spelled "shud", 'cause it is a four letter word.

>> Ok, but there are two such numbers.  Minus zero and plus zero are
>> both allowed as results of that operation.
>
>Why not three?  Minus zero, plus zero, and blank zero?
>
>> Which of those is "exact" zero?
>
>...
>
>As far as I am concerned, there is only one exact zero, not two, and
>not three, and there should be no sign associated with an exact zero.

Part of the problem here is that people "think" that zero should be
simple.  But it is NOT simple.  The same issue arises with infinity,
but in that case no one is surprised, after all, infinity should be
difficult.


Consider the complex numbers.  In cartesian representation (i.e.,
real and imaginary), zero is (apparently) simple.  There is only
one "zero".  Now try to define infinity, and you need infinitely
many infinities.  

But reconsider the complex numbers in polar representation (i.e.,
magnitude and angle), and clearly "zero" is not so simple any more.
There are infinitely many representations for complex zero, all
with zero magnitude but with arbitrary angle, just as there are
infinitely many representations for infinity.

Finally, consider the complex numbers geometrically, as the
complex plane which can be mapped to a unit sphere uniquely,
with all points on the plane having a unique point on the sphere
to correspond, (the standard mapping is to have the unit circle
on the plane be the equator on the unit sphere, then rays from
the "north pole" of the sphere downward intersect the plane in but
one point and the sphere in but one point, establishing a 1-1
mapping).  In this representation, a unique point at infinity 
can be defined to be the one point on the sphere which is not 
mapped to the plane, i.e., the "north pole".  There is a SINGLE
unique point called "zero" and a single unique point called
"infinity".

Which of these three representations for complex numbers is 
right?  (Trick question)  ALL THREE ARE.

So is complex infinity singular or infinite in representation?  Answer,
depends upon the representation chosen.

So is complex zero singular or infinite in representation?  Answer,
depends upon the representation chosen.

Then we add machine representation issues to the theoretical representation
issues and add yet another layer of complexity needing interpretation.

NO, ZERO IS NOT A SIMPLE CONCEPT.  AND REPRESENTATIONS OF ZERO CANNOT
BE PRESEUMED TO BE SIMPLE, EVEN THOUGH SOME REPRESENTATIONS MANAGE TO
ACHIEVE A CERTAIN DECEPTIVE SIMPLICITY.

>You might erroneously propagate the error using
>
>   dz**2 = dx**2 + dy**2
>
>for the case
>
>   z = x + y
>
>the error being due to the fact that x and y are anticorrelated.  How is
>interval arithmetic going to know that?

Actually that is the UNcorrelated case, for ANTIcorrelated you would use

dz = |dx - dy|

Jan Vorbr�ggen wrote:
>> Yes, but usually the computational error is smaller than other
>> sources of error.  When they're not, higher precision is necessary. I 
>> rarely use REAL*4 for the physical problems I deal with.  REAL*8
>> is almost always adequate.
>
> But why would REAL*4, with its LSB relative error of about 10^-7, not
> be adequate for most physical computation? I sure never measured
> anything to even remotely that precision...

Relative error grows.  As you do more calculations, the
consequences of round-off accumulation destroys the
validity of your answers.  Take weather forcasting:
double precision allows finer time-steps, finer spatial
gridding, and simulates further into the future with more
accurate forcasts.  This is objectively verified by comparing
the results of the codes with wha happens outside.

If you don't see this in your work, then you're probably
not doing simulations.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ....

>> Why should the sign bit be set if the magnitude is zero?

> It's often decisive information.  It's up to th euser to know if it
> matters - it's *NOT* up to the implementation to arbitrarily decide
> for the user.  If it worries you, be content that I don't know any
> implementations that set the sign bit for zeros that result from
> sums or differences.  The IEEE standard allows either sign
> in such a case.  For underflow the sign almost always carries
> useful information.  The implementation should never supress
> it.

But

  Z = (Y - X)/A

and

  Z = Y/A - X/A

are algebraically equivalent.  Suppose (Y - X)/A underflows, but
neither Y/A or X/A underflows, and the sign bit wouldn't be set
for the difference.

>>> And, if you're simulating genuine real numbers with your floating
>>> point REAL data type, you'll *never* see something you're sure
>>> is an exact zero.

>> Why not?  Suppose I difference two real numbers that have the exact
>> same internal representation.

> Then the *actual* difference is approximately the same magnitude
> as the error in the least accurately calculated of the two operands.
> For nearly all calculations that's a lots bigger than zero.

You're assuming that the numbers are calculated.  I had previously
given an example in which the numbers being differenced were
assigned, not calculated (or manipulated, to use my previous term).

>>> Suppose you have a record of temperatures recorded at some
>>> observing site and you go through generating a first-difference
>>> (an approximation to a derivative).  Well, the thermometer reports
>>> to a tenth of a degree.  Suppose two consecutive times show a
>>> value of 15 degrees.  That means each value is actually somewhere
>>> between 14.95 and 15.05 degrees and whatever true temp occurred
>>> was rounded to just 15.0 degrees.  The float difference of those two
>>> measurements will have a magnitude of zero.  But, it's pretty clear
>>> that the temps at the two times were almost certainly more different
>>> than the ~10^(-39) precision of floating point!  That zero difference
>>> is hardly *exact*  (in fact, the correct answer is in the interval
>>> from -0.1 through 0.1, somewhere).  The sign printed with a zero
>>> arising from such a calculation is meaningless, why do you care
>>> which is printed?

>> You're assuming that I would want one or the other printed.  In such
>> a case, I would be content to have no sign.  It's up to the user to
>> properly interpret the results of a calculation.

> And it's not up to the implementation to make that decision for
> him(her).  If it's up to the user, leave the sign there and let
> the user decide.  Never lie to the user.

Suppose in your temperature example, the first value was really
15.01 and the second value was 14.99, but the implementation
couldn't know that and used a plus sign, thus lying to the user.
Indeed, if forced to display a sign in that example, there's a
fifty percent chance of lying to the user.

>> If the sign bit carries decisive information, then it's important
>> for the correct sign to be displayed.  In your temperature example
>> above, you noted that the correct answer could be either positive
>> or negative, so there is no way for the processor to know which is
>> the correct sign, thus I would argue it's important to suppress the
>> sign.

> But, an absent sign *means* positive zero!

I disagree.

> Supressing it has no advantages.  It helps no one.

Again, I disagree.  See above for an example.

jvorbrueggen@not-mediasec.de writes:

>> Yes, but usually the computational error is smaller than other sources
>> of error.  When they're not, higher precision is necessary.  I rarely
>> use REAL*4 for the physical problems I deal with.  REAL*8 is almost
>> always adequate.

> But why would REAL*4, with its LSB relative error of about 10^-7, not be 
> adequate for most physical computation? I sure never measured anything to even 
> remotely that precision...

The distance of the Earth from the Sun is known to nine digits.

Kevin G. Rhoads writes:

>> You might erroneously propagate the error using
>>
>>    dz**2 = dx**2 + dy**2
>>
>> for the case
>>
>>    z = x + y
>>
>> the error being due to the fact that x and y are anticorrelated.  How is
>> interval arithmetic going to know that?

> Actually that is the UNcorrelated case,

Incorrect.  Uncorrelated means that the correlation coefficient is zero,
and changes in x are completely independent of changes in y.  Anticorrelated
means that the correlation coefficient is -1, and that's the case for the
example I gave, because if you increase x by delta, you decrease y by delta.

> for ANTIcorrelated you would use
>
> dz = |dx - dy|

Kevin G. Rhoads writes:

>>> Ok, but there are two such numbers.  Minus zero and plus zero are
>>> both allowed as results of that operation.

>> Why not three?  Minus zero, plus zero, and blank zero?

>>> Which of those is "exact" zero?

>> ...
>>
>> As far as I am concerned, there is only one exact zero, not two, and
>> not three, and there should be no sign associated with an exact zero.

> Part of the problem here is that people "think" that zero should be
> simple.  But it is NOT simple.  The same issue arises with infinity,
> but in that case no one is surprised, after all, infinity should be
> difficult.
>
> Consider the complex numbers.  In cartesian representation (i.e.,
> real and imaginary), zero is (apparently) simple.  There is only
> one "zero".  Now try to define infinity, and you need infinitely
> many infinities.  
>
> But reconsider the complex numbers in polar representation (i.e.,
> magnitude and angle), and clearly "zero" is not so simple any more.
> There are infinitely many representations for complex zero, all
> with zero magnitude but with arbitrary angle, just as there are
> infinitely many representations for infinity.

In a polar representation, one does not have a minus zero.

> Finally, consider the complex numbers geometrically, as the
> complex plane which can be mapped to a unit sphere uniquely,
> with all points on the plane having a unique point on the sphere
> to correspond, (the standard mapping is to have the unit circle
> on the plane be the equator on the unit sphere, then rays from
> the "north pole" of the sphere downward intersect the plane in but
> one point and the sphere in but one point, establishing a 1-1
> mapping).  In this representation, a unique point at infinity 
> can be defined to be the one point on the sphere which is not 
> mapped to the plane, i.e., the "north pole".  There is a SINGLE
> unique point called "zero" and a single unique point called
> "infinity".
>
> Which of these three representations for complex numbers is 
> right?  (Trick question)  ALL THREE ARE.
>
> So is complex infinity singular or infinite in representation?  Answer,
> depends upon the representation chosen.
>
> So is complex zero singular or infinite in representation?  Answer,
> depends upon the representation chosen.
>
> Then we add machine representation issues to the theoretical representation
> issues and add yet another layer of complexity needing interpretation.
>
> NO, ZERO IS NOT A SIMPLE CONCEPT.  AND REPRESENTATIONS OF ZERO CANNOT
> BE PRESEUMED TO BE SIMPLE, EVEN THOUGH SOME REPRESENTATIONS MANAGE TO
> ACHIEVE A CERTAIN DECEPTIVE SIMPLICITY.

The issue that Giles and I were discussing wasn't whether zero is a
simple concept, but rather the sign of zero.  In your polar representation
example, you actually made life easier, because there is no negative zero.

Gordon Sande writes:

>> James Giles wrote:

>>> ....

>>>> Maybe I've misunderstood the earlier discussion, but I thought that
>>>> minus zero applied only to cases where the actual numerical value
>>>> was in fact negative, but the chosen display format was insufficient
>>>> to show any significant digits, therefore the number would be
>>>> displayed as all zeros, with the question being whether to display
>>>> the minus sign or not.  For example, should the value -1.2E-5, when
>>>> displayed with the format edit descriptor F4.1, be -0.0 or  0.0?

>>> That's easy, the Fortran standard says that a negative value should
>>> have a minus sign output.  The earlier discussion was more concerned
>>> over whether an internal value was negative or not, when its magnitude
>>> was zero but it had a set sign bit.  The rule should be more clearly
>>> stated in the standard: if the sign bit is set the output should begin
>>> (after any padding blanks) with a minus sign.  That's independent of
>>> the magnitude (infact, I think that should be the rule even if the
>>> number turns out to be NaN).

>> Why should the sign bit be set if the magnitude is zero?

> Two analogies:
>
> 1. Font hinting is something that is not true in some restricted and narrow
>    sense but it sure makes a lot of things a lot smoother.

I fail to see the analogy in this case.

> 2. Extended reals are a valid mathematical system that you may not be familiar
>    with that shares many properties with the reals and also permits various
>    additional operations to proceed gracefully. (There are even some rather
>    "wild" systems that mimic what you would think of as ordinary arithmetic
>    but that lead to a lot of interesting (at least to those who study them)
>    mathematics.)

I'm not familiar with what you have briefly described, thus it's hard
to see any analogy here as well.

> Signed zeros may not be what you are used to or were taught in an earlier
> mathematics course but they do make a lot of things proceed more gracefully
> if used according to their intended rules. You can view the signed zeros as
> hints of their history which can be important in many analytic applications
> or as a similar formal system with only a few rules changed.

They may make some (or even a lot) of things proceed more gracefully,
but not everything.

> The usual rule of "if you don't like it then don't use it" applies with
> the additional comment that you may have to ignore some negaive signs
> on a few zeros supplied by others.

Suppose someone likes them and chooses not to ignore them, but the
situation is like Giles' temperature example, in which the processor
can't know which sign is the correct sign.  Accept a fifty percent
chance of getting it wrong, or suppress it?

>>>> As far as I am concerned, there is only one exact zero, not two, and
>>>> not three, and there should be no sign associated with an exact zero.

>>> And, if you're simulating genuine real numbers with your floating
>>> point REAL data type, you'll *never* see something you're sure
>>> is an exact zero.

>> Why not?  Suppose I difference two real numbers that have the exact
>> same internal representation.

>>> Suppose you have a record of temperatures recorded at some
>>> observing site and you go through generating a first-difference
>>> (an approximation to a derivative).  Well, the thermometer reports
>>> to a tenth of a degree.  Suppose two consecutive times show a
>>> value of 15 degrees.  That means each value is actually somewhere
>>> between 14.95 and 15.05 degrees and whatever true temp occurred
>>> was rounded to just 15.0 degrees.  The float difference of those two
>>> measurements will have a magnitude of zero.  But, it's pretty clear
>>> that the temps at the two times were almost certainly more different
>>> than the ~10^(-39) precision of floating point!  That zero difference
>>> is hardly *exact*  (in fact, the correct answer is in the interval from
>>> -0.1 through 0.1, somewhere).  The sign printed with a zero arising
>>> from such a calculation is meaningless, why do you care which is
>>> printed?

>> You're assuming that I would want one or the other printed.  In such
>> a case, I would be content to have no sign.  It's up to the user to
>> properly interpret the results of a calculation.

>>> In using float to simulate continuous real arithmetic, zeros
>>> can arise a number of ways.  They reduce to two categories:
>>> 1) underflow, where the sign bit still carries useful (maybe
>>> decisive) information; 2) result of discrete approximation
>>> (like the above difference) where the sign bit means nothing
>>> and a good programmer knows it.  There are no third cases,
>>> that is, where it's actually *important* to supress the sign.

>> If the sign bit carries decisive information, then it's important
>> for the correct sign to be displayed.  In your temperature example
>> above, you noted that the correct answer could be either positive
>> or negative, so there is no way for the processor to know which is
>> the correct sign, thus I would argue it's important to suppress the
>> sign.

>>> Now if you are using floating point to do some kind of discrete
>>> arithmetic rather than as a surrogate for continuous reals, the
>>> sign bit of zero may or may not be important (usually not).
>>> However, I can still see no reason for the implementation
>>> to supress it.

>> Consider your temperature example.  The sign could be misleading
>> if not suppressed.

tholen@antispam.ham wrote:
> But
>
>  Z = (Y - X)/A
>
> and
>
>  Z = Y/A - X/A
>
> are algebraically equivalent.  Suppose (Y - X)/A underflows, but
> neither Y/A or X/A underflows, and the sign bit wouldn't be set
> for the difference.

If you expect algebraic equivalence to result in computational
equivalence you're *really* clueless about numerical computing.
No float arithemetic always obeys the distributive or associative
rules.  Fact of life.  Live with it.

Assuming both the above result with a zero value of Z (of some
sign), they'll compare equal.  That's more than you've any right
to expect.

I wrote:
>> Then the *actual* difference is approximately the same magnitude
>> as the error in the least accurately calculated of the two operands.
>> For nearly all calculations that's a lots bigger than zero.
>
> You're assuming that the numbers are calculated.  I had previously
> given an example in which the numbers being differenced were
> assigned, not calculated (or manipulated, to use my previous term).

And you *know* those assigned values are *infinitely* accurate?
I'm astonished.  What were the units of measure that you used
to find numerical constants that can be written in a finite decimal
literal, that convert *exactly* to a binary float representation,
and are *infinitely* accurate with some genuine physical meaning?
That's some feat!  And, if you already know they're equal, why
are you subtracting them?  Surely just assigning 0.0 instead of
using an expression is better?

> Suppose in your temperature example, the first value was really
> 15.01 and the second value was 14.99, but the implementation
> couldn't know that and used a plus sign, thus lying to the user.

That's that *you've* been requesting!  A plus sign and an absent sign
has *identical* meaning.  Any case, the float implementation didn't
have the *actual* numbers and does the best it can.  It can't reinvent
the missing information.  The thermometer rounded to the nearest
tenth and that's that.

The I/O implementation *does* have sign information and you
advocate throwing it away.  That's *not* the best it can do.  You're
destroying information.

>> But, an absent sign *means* positive zero!
>
> I disagree.

Go ahead.  You can pretend that when I say "tea" it doesn't
mean a beverage if you choose.  You will not be showing much
rational inclination for communicating with others if you do.  I'm
telling you what the meaning of signs is within the IEEE standard.
They weren't particularly interested in numerological mysticism
when they designed the floating point representation.  They had
practical problems to solve.  Signed zeros are an advance on
previous floating point implementations: if they're meaningless
you can ignore them (but that should be each user's choice, the
I/O implementer should not be able to force an arbitrary decision
on others), often they aren't meaningless - often they're important.
They do *NO* damage when they're meaningless.  They help a lot
when they're not.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
> Gordon Sande writes:
....
> Suppose someone likes them and chooses not to ignore them, [...]

"Likes them"?  Why would any choose on that basis?  The
signs have meaning or they don't.  The interpretation of them is
up to the user.  The user decides for utilitatian reasons.  The
utility of the signs *cannot* be known by the author of the
I/O library.  The I/O library should *never* disregard them.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

glen herrmannsfeldt wrote:
> tholen@antispam.ham wrote:
>
> (snip)
>
>> The issue that Giles and I were discussing wasn't whether zero is a
>> simple concept, but rather the sign of zero.  In your polar
>> representation example, you actually made life easier, because there
>> is no negative zero.
>
> Well, there is 0 with phase 0 and zero with phase pi, and zero with
> phase pi/2 (imaginary zero), and zero with phase -pi/2 (negative
> imaginary zero), and...

In fact, in the Common Lisp language signum() return a unit
with the same sign as the argument.  But with a complex arg,
it returns a value with unit magnitude and the same phase
as the argument.  Obviously phase is a similar concept to
sign.  (In lisp, signum(X), for non-zero X is defined to be
 X/abs(X), for all numeric data types).

(Indeed, one of the few disagreements I have with Common Lisp
is that on zero arguments signum() discards the sign and returns
just zero.  At the very least, if X is zero, signum(X) should be X.)

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:

(snip)

> The issue that Giles and I were discussing wasn't whether zero is a
> simple concept, but rather the sign of zero.  In your polar representation
> example, you actually made life easier, because there is no negative zero.

Well, there is 0 with phase 0 and zero with phase pi, and zero with
phase pi/2 (imaginary zero), and zero with phase -pi/2 (negative 
imaginary zero), and...

-- glen

tholen@antispam.ham wrote:

(snip)

> The distance of the Earth from the Sun is known to nine digits.

To which part of the sun?  And at what time?

(Remember, the earth's orbit is an ellipse.)

-- glen

James Giles writes:

>> Gordon Sande wrote:

> ....

>> Suppose someone likes them and chooses not to ignore them, [...]

> "Likes them"?  Why would any choose on that basis?  The
> signs have meaning or they don't.  The interpretation of them is
> up to the user.  The user decides for utilitatian reasons.  The
> utility of the signs *cannot* be known by the author of the
> I/O library.  The I/O library should *never* disregard them.

In which case the I/O library had better get them right.  But in
your temperature example, there's a fifty percent chance of getting
it wrong.

glen herrmannsfeldt writes:

> (snip)

>> The distance of the Earth from the Sun is known to nine digits.

> To which part of the sun?

Center of mass.

> And at what time?

Time is an argument to the ephemeris computation, so take your pick.
Sure, if you pick a time far enough into the future, you can accumulate
enough uncertainty to reduce the accuracy to eight digits, but the
current ephemeris covers a few hundred years to nine digit accuracy.

> (Remember, the earth's orbit is an ellipse.)

Actually, when perturbations are taken into account, it's not even
an ellipse, but rather more complicated than that.  The current
ephemeris takes all that into account.

tholen@antispam.ham wrote:
> James Giles writes:
....
>> "Likes them"?  Why would any choose on that basis?  The
>> signs have meaning or they don't.  The interpretation of them is
>> up to the user.  The user decides for utilitatian reasons.  The
>> utility of the signs *cannot* be known by the author of the
>> I/O library.  The I/O library should *never* disregard them.
>
> In which case the I/O library had better get them right.  But in
> your temperature example, there's a fifty percent chance of getting
> it wrong.

We've already addressed that point ad-nauseam.  You repeating
the same misdirection helps your cause none at all.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

>> But
>>
>>  Z = (Y - X)/A
>>
>> and
>>
>>  Z = Y/A - X/A
>>
>> are algebraically equivalent.  Suppose (Y - X)/A underflows, but
>> neither Y/A or X/A underflows, and the sign bit wouldn't be set
>> for the difference.

> If you expect algebraic equivalence to result in computational
> equivalence you're *really* clueless about numerical computing.

Isn't the processor free to do that?  You recently gave the example
of SQRT(X*X) being replaced by the equivalent ABS(X).

> No float arithemetic always obeys the distributive or associative
> rules.  Fact of life.  Live with it.
>
> Assuming both the above result with a zero value of Z (of some
> sign), they'll compare equal.  That's more than you've any right
> to expect.

You've raised yet another interesting concept:  equality.  Is a
negative zero equal to a positive zero?

>>> Then the *actual* difference is approximately the same magnitude
>>> as the error in the least accurately calculated of the two operands.
>>> For nearly all calculations that's a lots bigger than zero.

>> You're assuming that the numbers are calculated.  I had previously
>> given an example in which the numbers being differenced were
>> assigned, not calculated (or manipulated, to use my previous term).

> And you *know* those assigned values are *infinitely* accurate?

I expect that two variables initialized to the same value will have
the same internal representation.  That is

  X = 1.0
  Y = 1.0

X and Y better have the same internal representation.  When you
difference them, I consider that to be an exact zero.

> I'm astonished.  What were the units of measure that you used
> to find numerical constants that can be written in a finite decimal
> literal, that convert *exactly* to a binary float representation,
> and are *infinitely* accurate with some genuine physical meaning?

You're presupposing that I know the assigned values are infinitely
accurate.  I never said that.  All I said is that their internal
representations are the same, such that when you difference them,
you get an exact zero.  Conversly, it's entirely possible that in

  X = 1.000000000000000000000000000000000000000001
  Y = 1.0

X and Y will have the same internal representation, thus the
difference would be an exact zero, yet their difference is
clearly not zero, and could be represented by the processor
(as +/- 1.0E-N, with the sign depending on which way you do
the differencing).

> That's some feat!  And, if you already know they're equal, why
> are you subtracting them?

To demonstrate my concept of an exact zero.  Nothing more.  That is,
after all, what you asked about.  Just trying to answer your question
in an understandable way.

> Surely just assigning 0.0 instead of
> using an expression is better?

If I had done that, would it have demonstrated my concept of an
exact zero any better for you?

But you've raised yet another interesting concept:  can the user
initialize a variable with a minus zero?  Or alternatively, when
the user initializes a variable to zero, did he give it a plus
zero or a minus zero?  Initialzing a variable to zero is extremely
common, after all.  Lots of compilers initialize all numeric
variables to zero.  Are they plus zero, minus zero, or perhaps
an exact zero, if you accept such a concept?

>> Suppose in your temperature example, the first value was really
>> 15.01 and the second value was 14.99, but the implementation
>> couldn't know that and used a plus sign, thus lying to the user.

> That's that *you've* been requesting!

Not at all.

> A plus sign and an absent sign has *identical* meaning.

Not according to the above example.

> Any case, the float implementation didn't
> have the *actual* numbers and does the best it can.  It can't reinvent
> the missing information.  The thermometer rounded to the nearest
> tenth and that's that.

So there's no way for the processor to know which sign to assign.

> The I/O implementation *does* have sign information

How?  The thermometer destroyed it.

> and you advocate throwing it away.

I do not advocate throwing away information.  I advocate not misleading
the user into thinking there is information present when there isn't.

> That's *not* the best it can do.  You're destroying information.

How so?  It's the thermometer that destroyed the information by rounding
to the nearest tenth, and that's that.  The result was a difference of
zero, and there's no way to know whether the difference should have been
positive or negative.

>>> But, an absent sign *means* positive zero!

>> I disagree.

> Go ahead.  You can pretend that when I say "tea" it doesn't
> mean a beverage if you choose.  You will not be showing much
> rational inclination for communicating with others if you do.

By talking about *infinitely* accurate above, you did not show any
inclination for communicating with me, because that's not at all
what I was talking about.

> I'm
> telling you what the meaning of signs is within the IEEE standard.

I'm telling you that there can be cases where the sign can't be
known to the processor, therefore to display a sign could be
misleading.

> They weren't particularly interested in numerological mysticism
> when they designed the floating point representation.

Neither am I.

> They had
> practical problems to solve.  Signed zeros are an advance on
> previous floating point implementations:

Only if people know how to interpret them properly, and only if
they are assigned properly.  I've never had a compiler manual
document how it assigns the sign of a zero result, so how is the
user supposed to know how to interpret them?

> if they're meaningless you can ignore them

You're assuming that the user will always know when they're
meaningless.  That could be easy in simple cases.  What about
complex cases, where the number you get out at the end is the
result of thousands or millions of intermediate calculations?

> (but that should be each user's choice, the
> I/O implementer should not be able to force an arbitrary decision
> on others),

Exactly.  In your thermometer example, the decision is arbitrary.

> often they aren't meaningless - often they're important.
> They do *NO* damage when they're meaningless.

That assumes the user knows they're meaningless.

> They help a lot when they're not.

>Incorrect.

What you say in this post is exactly what I said in the post to which it was 
a reply to, so how do you claim "incorrect"?

The sqrt of sum of the squares is the UNcorrelated case,
the difference is the anti-correlated case.  That is what
I claimed two posts back, and what you claimed one post back --
so ???

>The issue that Giles and I were discussing wasn't whether zero is a
>simple concept, but rather the sign of zero. 

But the sign of zero is an issue, in part, because zero is not simple.

1 is simple, so +1 or -1 are correspondingly simple.   Zero is NOT
simple, so signs for zero become more an issue because of the
in-simplicity of zero.  

If you continue to ignore that zero, itself, is not simple, then
it is very hard, perhaps impossible, to do justice to the issues
of a sign for it.

You also seem to have glossed over the whole matter of representations,
both theoretical and machine, which is intimately related to problems
of the sign of zero in computers.

Your choice, but I think it hard to do justice to the sign of zero
when ignoring the issues of zero.

James Giles writes:

> ....

>>> "Likes them"?  Why would any choose on that basis?  The
>>> signs have meaning or they don't.  The interpretation of them is
>>> up to the user.  The user decides for utilitatian reasons.  The
>>> utility of the signs *cannot* be known by the author of the
>>> I/O library.  The I/O library should *never* disregard them.

>> In which case the I/O library had better get them right.  But in
>> your temperature example, there's a fifty percent chance of getting
>> it wrong.

> We've already addressed that point ad-nauseam.  You repeating
> the same misdirection helps your cause none at all.

It's the processor's misdirection, if it displays a sign on the
zero, not mine.  You repeatedly ignoring the fifty percent
probability of the processor getting it wrong helps your cause
none at all.

Kevin G. Rhoads writes:

>> Incorrect.

> What you say in this post is exactly what I said in the post to which it was 
> a reply to,

No, it isn't.  Which may explain why you removed it from your follow-up.  So
let's restore it:

]] the error being due to the fact that x and y are anticorrelated.  How is
]] interval arithmetic going to know that?

] Actually that is the UNcorrelated case,

x in the example was the distance between A and B, and y was the distance
between B and C, where the positions of A and C were extremely well known,
while the position of B was very poorly known.

> so how do you claim "incorrect"?

Because it is incorrect to describe the example I gave as a case of
uncorrelated variables.

> The sqrt of sum of the squares is the UNcorrelated case,

Which is why using the sum of the squares is an error, because x and y are
not uncorrelated.  That's why I said "the error being due".

> the difference is the anti-correlated case.  That is what
> I claimed two posts back,

On the contrary, you claimed that x and y are uncorrelated, but in the
example I provided, they are clearly anticorrelated.

> and what you claimed one post back -- so ???

Yes, I did claim that x and y are anticorrelated in the example I gave.
That's because they are.

To summarize:

Point one: when used to simulate the continuous real numbers,
   floating point is *always* inexact.  There is no "exact zero",
   or any other real number.  There are only approximations.
   There is no such thing as an "exact zero" (or any other "exact"
   number) when using float for simulating continuous reals
   because that's an inherent property of the use of *any* discrete
   representation to simulate continuous values.   Nor is there any
   reason zeros can't have signs.  Numbers were invented by people.
   People have in fact invented several thousand different kinds
   of mathematics (my introductory abstract algebra course covered
   nearly a hundred).  To invent a number system with signed
   zeros is neither shocking nor illicit.  It's damned useful.  Claiming
   that zeros *can't* have signs under any circumstances because
   of some inherent characteristics they have is correctly identified
   as numerological mysticism.   In a given invented number system,
   signs can adorn anything the inventors want them to.

Point two: on output the I/O implementation should always
   correctly display a minus sign if the number's internal sign
   bit was set.  This is true for all magnitudes of values being
   output.  Not to do so is irresponsible.

Now, another contributor to this thread consistently confuses
these separate points.  They have nothing to do with one another.
A clear demonstration of the fact that differences of identically
represented numbers are *not* exact zeros verifies the first
point.  Nothing about that example is relevant to the second
point in any way at all.  Similarly,since the I/O library has
no idea about the origin or meaning of

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

>> What you say in this post is exactly what I said in the post to which it was 
>> a reply to,
>
>No, it isn't.  Which may explain why you removed it from your follow-up.  So
>let's restore it:

Actually if you plan to "restore" anything, restore it all.

You were explaining that the sqrt of the sum of the squares did NOT
apply to the anti-correlated case (way back) and I missed the "NOT"
part and explained that sqrt of sum of squares applied to the UNcorrelated
case.

THen YOU MISSED that my explanantion was correct but inapplicable, and
attempted to "correct" it by providing the same explanation.

THe post of yours that I replied to originally had NO error.  But
my explanation in response to it was, in fact, correct.  My error 
was NOT in my explanation, but in the fact that I was explaining
something you had already gotten  correct.  Your error in response
is, apparently, the same.

Go back and re-read the thread carefully.  I think you will find 
we were accidentally talking at cross-purposes, each responding
to what we thought had been written as opposed to what actually
had been written.

In any case, I see no reason to continue.  We agree on how 
both UN- and anti- correlated errors combine, and all else
was miscommunication.

tholen@antispam.ham wrote:
....
> It's the processor's misdirection, if it displays a sign on the
> zero, not mine.  You repeatedly ignoring the fifty percent
> probability of the processor getting it wrong helps your cause
> none at all.


Sigh... I've answered this too many times.  I ignored nothing.
I was the first that stated the sign on the output of that *particular*
example was irrelevant.  But, the sign is present like it or not.
No sign means the same as a plus sign.  I don't care whether
you agree - it's the truth.  There are only two possibilities:
plus zero of minus zero.  There is no third choice.   There's
not going to be a third choice.  Get used to it.  It's a fact of
computing.

Nor is this example even remotely relevant the the question
of what the I/O library should do with the sign of zero.  The I/O
library *must* output all it knows.  That includes a correct
indication of the sign of the value being printed.  This is a
very simple concept: the I/O library can't discern the meaning
of the value or whether the sign is meaningful or not.  I don't
see how anyone can fail to grasp such a simple concept.

What rule for magically discovering whether the sign has
meaning or not do you propose?  Give specifics.  Since you
have repeatedly asked "what if the user doesn't know if the
sign is meaningful or not?", your magical decision making
method can't rely on user input.  If the user doesn't know
when reading the output, (s)he can't know at compile time
either.  Unless you're planning to *always* supress the
zero?  Ok, but no one will think your method is in the least
useful.  You'll be disregarded entirely (and correctly
so).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
(snip)

> But you've raised yet another interesting concept:  can the user
> initialize a variable with a minus zero?  Or alternatively, when
> the user initializes a variable to zero, did he give it a plus
> zero or a minus zero?  Initialzing a variable to zero is extremely
> common, after all.  Lots of compilers initialize all numeric
> variables to zero.  Are they plus zero, minus zero, or perhaps
> an exact zero, if you accept such a concept?

You can always use a BOZ constant and the REAL function to
initialize to any bit representation.  It might be that they
won't initialize to negative zero, though IEEE might require it.

I believe on most processors X=-X will change the sign of X, even
if it is zero.  I know it will on S/360 and successors, and I
believe it is also required for IEEE floating point.

-- glen

James Giles <jamesgiles@worldnet.att.net> wrote:
> tholen@antispam.ham wrote:

> > You're assuming that the numbers are calculated.  I had previously
> > given an example in which the numbers being differenced were
> > assigned, not calculated (or manipulated, to use my previous term).

> And you *know* those assigned values are *infinitely* accurate?
> I'm astonished.

There are applications where it makes sense to consider the inputs
as exact and where it would be a hell of a lot more trouble to do
otherwise.

    http://www.cs.cmu.edu/~quake/robust.html


-- 
pa at panix dot com

tholen@antispam.ham wrote:

> glen herrmannsfeldt writes:
>>(snip)

>>>The distance of the Earth from the Sun is known to nine digits.

>>To which part of the sun?

> Center of mass.

The center of mass of the sun, or of the solar system?
(I tried looking on the JPL web site, but I didn't see much to say.)

>>And at what time?

> Time is an argument to the ephemeris computation, so take your pick.
> Sure, if you pick a time far enough into the future, you can accumulate
> enough uncertainty to reduce the accuracy to eight digits, but the
> current ephemeris covers a few hundred years to nine digit accuracy.

Well, that too, but time uncertainty will propagate to distance
uncertainty.  If I figured it out right, a two second uncertainty
in time is about 1e-9 in relative distance.

>>(Remember, the earth's orbit is an ellipse.)

> Actually, when perturbations are taken into account, it's not even
> an ellipse, but rather more complicated than that.  The current
> ephemeris takes all that into account.

The ephemeris takes it into account, but one has to be precise in
the question being asked.  I will guess that the difference between
the CM of the sun and the CM of the solar system is more than
1e-9 AU.

-- glen

In article <5gbv1lF3cjnocU1@mid.individual.net>, Jan Vorbr�ggen wrote:
> But why would REAL*4, with its LSB relative error of about 10^-7, not be 
> adequate for most physical computation? I sure never measured anything to even 
> remotely that precision...

The distance from the earth to the sun was already mentioned as one
such measurement. Another, even more accurate, measurement is that of
the electron g-factor. In fact, AFAIK it is the most exactly known
quantity in all of physics. The latest measurements are supposedly
accurate to 7.6 parts in 10**13.

http://cerncourier.com/cws/article/cern/29724


-- 
Janne Blomqvist

Kevin G. Rhoads writes:

>> The issue that Giles and I were discussing wasn't whether zero is a
>> simple concept, but rather the sign of zero. 

> But the sign of zero is an issue, in part, because zero is not simple.

That doesn't mean the issue we were discussing included the lack of
simplicity of zero.

> 1 is simple, so +1 or -1 are correspondingly simple.   Zero is NOT
> simple, so signs for zero become more an issue because of the
> in-simplicity of zero.  

That still doesn't mean the issue we were discussing included the lack
of simplicity of zero.

> If you continue to ignore that zero, itself, is not simple, then
> it is very hard, perhaps impossible, to do justice to the issues
> of a sign for it.

You're erroneously presupposition that I'm ignoring that zero is not
simple.  I know it is complex.  In fact, it's so complex that simply
adding a plus or minus sign to zero isn't sufficient to deal with all
of the complexities.  Perhaps the +/- (single character) sign needs to 
be added.  I had the same thought as someone else about possibly using
the < and > characters.

> You also seem to have glossed over the whole matter of representations,
> both theoretical and machine, which is intimately related to problems
> of the sign of zero in computers.

What seems to you is irrelevant.

> Your choice, but I think it hard to do justice to the sign of zero
> when ignoring the issues of zero.

There is a big difference between limiting the discussion to one
particular issue and ignoring all other related issues.  Sometimes
it's necessary to focus.

James Giles writes:

> To summarize:
>
> Point one: when used to simulate the continuous real numbers,
> floating point is *always* inexact.

I disagree.  There is a subset of the continuous real numbers that
can be exactly represented with a finite number of bits.  Alternatively,
if one had an infinite number of bits to represent that subset, the
extra bits would all have the same status (on or off, depending on how
you chose to implement the representation).

For example, I cannot exactly represent the value for pi using a
finite number of decimal digits.  However, I can exactly represent
the value "one tenth" using a finite number of decimal digits.

> There is no "exact zero", or any other real number.

That is a semantic argument.  I provided one concept of an exact
zero.  I argue that it's a reasonable concept.  I've not seen anyone
offer a counter argument for it not being a reasonable concept.

> There are only approximations.
> There is no such thing as an "exact zero" (or any other "exact"
> number) when using float for simulating continuous reals
> because that's an inherent property of the use of *any* discrete
> representation to simulate continuous values.

Our decimal system is one of the "any" discrete reprsentations of
the continuous real values, and as I noted above, there is a
subset of the continuous real values that can be exactly represented.

> Nor is there any reason zeros can't have signs.

Agreed.  But that doesn't mean that zeros must always have signs.

> Numbers were invented by people.
> People have in fact invented several thousand different kinds
> of mathematics (my introductory abstract algebra course covered
> nearly a hundred).  To invent a number system with signed
> zeros is neither shocking nor illicit.  It's damned useful.  Claiming
> that zeros *can't* have signs under any circumstances because
> of some inherent characteristics they have is correctly identified
> as numerological mysticism.   In a given invented number system,
> signs can adorn anything the inventors want them to.

Irrelevant to the current discussion, because I'm not aware of
anyone who has claimed that zeros can't have signs.

> Point two: on output the I/O implementation should always
> correctly display a minus sign if the number's internal sign
> bit was set.  This is true for all magnitudes of values being
> output.  Not to do so is irresponsible.

That avoids the more fundamental question of how to decide when
to set that internal sign bit.  I once again refer you to your
thermometer example.  There is no way for the processor to know
whether to set it or not.

> Now, another contributor to this thread consistently confuses
> these separate points.

I'm not aware of any such contributor.

> They have nothing to do with one another.
> A clear demonstration of the fact that differences of identically
> represented numbers are *not* exact zeros verifies the first
> point.

On what basis do you claim that differences of identically
represented numbers are not exact zeros?

> Nothing about that example is relevant to the second
> point in any way at all.

But your thermometer example is relevant to the second point.

> Similarly,since the I/O library has
> no idea about the origin or meaning of

Of what?

James Giles writes:

> ....

>> It's the processor's misdirection, if it displays a sign on the
>> zero, not mine.  You repeatedly ignoring the fifty percent
>> probability of the processor getting it wrong helps your cause
>> none at all.

> Sigh... I've answered this too many times.  I ignored nothing.

I disagree.

> I was the first that stated the sign on the output of that *particular*
> example was irrelevant.

Which is your justification for ignoring it.

> But, the sign is present like it or not.

Only because you insist that a sign must be present.  As I noted
in another posting, the situation is more complex than that.

> No sign means the same as a plus sign.

Doesn't have to be that way.  Sure, in a binary representation, if
you allocate only a single bit to the sign, then you can have only
two states.  But we're talking about the external representation,
where in theory we can have many different characters, including
minus, plus, blank, greater than, less than, and even plus-minus.

> I don't care whether you agree - it's the truth.

Are you talking about the way things were, the way things are,
or the way things ought to be?

> There are only two possibilities:
> plus zero of minus zero.

A single sign bit can have only two states.  But the external
representation utilizes characters, and there are more than two
from which to choose.

> There is no third choice.   There's
> not going to be a third choice.  Get used to it.  It's a fact of
> computing.

I disgaree.  We now have double-byte character sets.  Why not
double bit signs?

> Nor is this example even remotely relevant the the question
> of what the I/O library should do with the sign of zero.  The I/O
> library *must* output all it knows.

Suppose it knows nothing, as in your thermometer example?

> That includes a correct
> indication of the sign of the value being printed.  This is a
> very simple concept: the I/O library can't discern the meaning
> of the value or whether the sign is meaningful or not.

Precisely.  So in your thermometer example, where the sign isn't
meaningful, the processor doesn't know that, thus it has a fifty
percent chance of getting it wrong by being forced to display a
sign.

> I don't
> see how anyone can fail to grasp such a simple concept.

Who here has failed to grasp that simple concept?  Have you
failed to grasp the fifty percent probability of getting the
sign wrong?

> What rule for magically discovering whether the sign has
> meaning or not do you propose?

You already gave the answer:  the precision of the thermometer
was limited to 0.1 deg.  Based on the limited amount I've been told
about interval arithmetic in this discussion, an implementation of
that sounds like it could do the job.

> Give specifics.  Since you
> have repeatedly asked "what if the user doesn't know if the
> sign is meaningful or not?", your magical decision making
> method can't rely on user input.

The user is frequently different from the programmer.  It's up
to the programmer to supply sufficient information so that the
user has what he needs.

> If the user doesn't know
> when reading the output, (s)he can't know at compile time
> either.

You're clearly assuming that the user is the same as the
programmer.  Hardly the norm.

> Unless you're planning to *always* supress the zero?

No.

> Ok, but no one will think your method is in the least
> useful.

You're proceeding from an erroneous presupposition.

> You'll be disregarded entirely (and correctly so).

You're still proceeding from an erroneous presupposition.

glen herrmannsfeldt writes:

>>> (snip)

>>>> The distance of the Earth from the Sun is known to nine digits.

>>> To which part of the sun?

>> Center of mass.

> The center of mass of the sun, or of the solar system?

Either.  JPL's software for reading and interpolating the Chebyshev
polynomial coefficients allows the user to specify his choice of
target and center.  I can only guess what the polynomial coefficients
in the binary file are referred to, but I would guess the barycenter.

> (I tried looking on the JPL web site, but I didn't see much to say.)

I suppose you could dig into the source code and reverse engineer it
to find the answer.

>>> And at what time?

>> Time is an argument to the ephemeris computation, so take your pick.
>> Sure, if you pick a time far enough into the future, you can accumulate
>> enough uncertainty to reduce the accuracy to eight digits, but the
>> current ephemeris covers a few hundred years to nine digit accuracy.

> Well, that too, but time uncertainty will propagate to distance
> uncertainty.  If I figured it out right, a two second uncertainty
> in time is about 1e-9 in relative distance.

Fortunately, atomic clocks offer stunning accuracy.

>>> (Remember, the earth's orbit is an ellipse.)

>> Actually, when perturbations are taken into account, it's not even
>> an ellipse, but rather more complicated than that.  The current
>> ephemeris takes all that into account.

> The ephemeris takes it into account, but one has to be precise in
> the question being asked.  I will guess that the difference between
> the CM of the sun and the CM of the solar system is more than
> 1e-9 AU.

Yes.  A lot more.  Jupiter has quite a lever arm.  The mass ratio is
0.001, but Jupiter is at 5 AU, which puts the barycenter 0.005 AU from
the CM of the Sun.

It's pretty amazing, the level of accuracy in celestial mechanics.
Telemetry from the Viking landers on Mars allowed folks at JPL to see
the gravitational perturbations on Mars from the asteroid Ceres.

Kevin G. Rhoads writes:

>>> What you say in this post is exactly what I said in the post to which it was 
>>> a reply to,

>> No, it isn't.  Which may explain why you removed it from your follow-up.  So
>> let's restore it:

> Actually if you plan to "restore" anything, restore it all.

I can do that, if necessary.

> You were explaining that the sqrt of the sum of the squares did NOT
> apply to the anti-correlated case (way back) and I missed the "NOT"
> part and explained that sqrt of sum of squares applied to the UNcorrelated
> case.

Actually, you only said "that" is the uncorrelated case.  Your statement
immediately followed my reference to x and y, thus it appeared as though
"that" referred to x and y.

> THen YOU MISSED that my explanantion was correct but inapplicable,

If "that" is taken to refer to my reference to x and y, then your
explanation was incorrect.  I didn't miss anything.  Rather, your
sentence was missing a crucial object.  See below.

> and attempted to "correct" it by providing the same explanation.
>
> THe post of yours that I replied to originally had NO error.

Glad you agree.  So it was logical to assume that when you posted a
statement that sounded like a correction, that you had identified
an error.

> But my explanation in response to it was, in fact, correct.

The part after the comma, where you gave the formula for the
anticorrelated case, is correct.  The part before the comma
uses an ambiguous "that".  You apparently meant for the "that"
to refer to the propagation of error equation and not the x and y
example.  Thus the correctness or incorrectness of the first part
of your statement depends on the interpretation of the "that".

> My error 
> was NOT in my explanation, but in the fact that I was explaining
> something you had already gotten  correct.  Your error in response
> is, apparently, the same.

Let's call it an ambiguity.  Interpretated one way, it's an error.
Interpreted the other way, it's not an error.

> Go back and re-read the thread carefully.

Unnecessary.

> I think you will find 
> we were accidentally talking at cross-purposes, each responding
> to what we thought had been written as opposed to what actually
> had been written.

What you actually had written was ambiguous because of the use of
"that".  Coincidentally, earlier in the week, I spent time with a
thesis student going over the typos in the thesis, and I pointed
out four instances of what I call the "naked this", which are cases
of "this" without a following noun, which have the potential for
leading to cases of ambiguity.  Your statement is a classic example
of why I call attention to the "naked this".  The ambiguity could
have been eliminated by writing "Actually that propagation of error
equation is the UNcorrelated case".

> In any case, I see no reason to continue.  We agree on how 
> both UN- and anti- correlated errors combine, and all else
> was miscommunication.

Agreed.

glen herrmannsfeldt writes:

> (snip)

>> On what basis do you claim that differences of identically
>> represented numbers are not exact zeros?

> They have zero significant bits.  How exact can they be?

The two internal representations were exactly the same.
That's means there is no difference between them.

If we want to get really freaky about it, we can talk about the
difference between two identical internal representations of an
exactly representable real number.

tholen@antispam.ham wrote:
> James Giles writes:
>
>> To summarize:
>>
>> Point one: when used to simulate the continuous real numbers,
>> floating point is *always* inexact.
>
> I disagree.  There is a subset of the continuous real numbers that
> can be exactly represented with a finite number of bits.

It's a small of shaped subset of the rationals..  If and only if *ALL*
your inputs, *ALL* your intermediate results, and *ALL* your results
are members of that set can you say that the arithmetic is exact.
And I've already said that several times.  So don't pretend you're
making any points.  If *any* one of those points isn't true you're
floating point is inexact..

It's comical that you focus on the *KNOWN* most error prone
operation in all of floating point as youtr shining example
of exactitude: subtract.  That shows such a complete lack
of understanding of the issues as to be astonishing.

>> There is no "exact zero", or any other real number.
>
> That is a semantic argument.  I provided one concept of an exact
> zero.  I argue that it's a reasonable concept.  I've not seen anyone
> offer a counter argument for it not being a reasonable concept.

What you offered is in conflict with the definitions of floating
point and comically with the common experience or users of
such numbers.  Subreact is the *shortest* path away from
exactitude.

>> Nor is there any reason zeros can't have signs.
>
> Agreed.  But that doesn't mean that zeros must always have signs.

But IEEE zeros always do.  Live with it.

>> Point two: on output the I/O implementation should always
>> correctly display a minus sign if the number's internal sign
>> bit was set.  This is true for all magnitudes of values being
>> output.  Not to do so is irresponsible.
>
> That avoids the more fundamental question of how to decide when
> to set that internal sign bit.  [...]

BUZZ.  The buzzer means you lose all your points and will have
to settle for your parting gifts.  This is point two now.  Yes, we
are here avoiding the fundamental question you mention.  Within
point two, it is *irrelevant* how the bit got set.  The only issue
is what the I/O library does with it.  You keep avoiding that
issue.  Which is strange since it's the principal subject of the
thread (see the subject line).

>> Now, another contributor to this thread consistently confuses
>> these separate points.
>
> I'm not aware of any such contributor.

You just did it!  You started in about a point one issue in response
to point two!  For the question about what the I/O implementation
does, *HOW* the bit got set is *irrelevant*.  The I/O library doesn't
know how the bit got set and therefore the decision can't be based
on that information.

> On what basis do you claim that differences of identically
> represented numbers are not exact zeros?

By definition.  The differences to two inexactly known quantities
can't be exact.  Since the purpose of floaing point is approximation
of continuous real numbers, they can *never* be regarded as exact.
The common observation of the programming community that
subtraction of similar values leaves essentially no significance
ought to be a clue.  That's an empirical observation about the
result of using float.  It most common to regard differences
resulting with zero with particular dismay - not only is the
relative error in the result *infinite*, the absolute error can't
even be estimated (not even to within a few orders of magnitude)
from just the value itself.  Zero, as a difference, usually carries
no useful information at all.

By the way, the IEEE standard states explicitly how the sign bit
gets set in *all* operations except the one case where it makes no
difference (at least, not to anyone that understands what floating
point is doing).  The only ambiguity is in your mind.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
(snip)

> On what basis do you claim that differences of identically
> represented numbers are not exact zeros?

They have zero significant bits.  How exact can they be?

-- glen

tholen@antispam.ham wrote:
> James Giles writes:
....
>> But, the sign is present like it or not.
>
> Only because you insist that a sign must be present.  As I noted
> in another posting, the situation is more complex than that.

No.  The sign bit exists whether you like it or not because the
IEEE standard says so.  It would still say so whether I insist
or not.  There's a bit in each floating point value representing
the sign.  That bit is always present.  It has one of two values.
That follows from the fact that it's a bit.  Nothing you've said
in any thread in any newsgroup at any time in the past or
even the future will make it more or less complex than
that.  It's actually pretty simple.

>> No sign means the same as a plus sign.
>
> Doesn't have to be that way.  Sure, in a binary representation, if
> you allocate only a single bit to the sign, then you can have only
> two states.  But we're talking about the external representation,
> where in theory we can have many different characters, including
> minus, plus, blank, greater than, less than, and even plus-minus.

And, you keep failing to specify what magic you think the I/O
library is going to use to infer more than one bit of information
from the one bit that's present.  The sign has two states.

Using a different convention for zero magnitude values still
leaves the necessity to report which of those two states the
sign bit was in.  And using said different notation just complicates
the language for no purpose,  The present convention of using
a minus sign if the sign bit is set, and a plus sign (or nothing at
all)  if the sign bit is clear answers admirably.  It tells the whole
story.  At least all of the story that the I/O library knows without
arbitrarily making up information out of the air!

>> That includes a correct
>> indication of the sign of the value being printed.  This is a
>> very simple concept: the I/O library can't discern the meaning
>> of the value or whether the sign is meaningful or not.
>
> Precisely.  So in your thermometer example, where the sign isn't
> meaningful, the processor doesn't know that, thus it has a fifty
> percent chance of getting it wrong by being forced to display a
> sign.

And it has a 100% chance of being wrong if it claims that the
answer is *exact* zero.  That's not an improvement.

The existing implementation is writing all zero digits for the
value already.  To anyone with an understanding of float, that
means the value (the result of a subtract), by itself, has no
significance at all, much less does the sign mean anything.

You keep claiming that the answer is being written wrong.
It isn't, you're just interpreting it wrong.  If you insist on
interpreting a notational convention differently than it was
intended, you'll continue to make mistakes.  As I said, you
can insist that when I say "tea" it doesn't mean a beverage:
you'll usually be wrong.

> The user is frequently different from the programmer.  It's up
> to the programmer to supply sufficient information so that the
> user has what he needs.

Then by gosh the programmer can write a string of plusses and
minuses or draw a picture of a clown if (s)he wants.  Just don't
lie to the later reader by pretending it to be the actual report of
the actual calculation.  Such an actual report can already be made
clearly by the output convention usually recommended.

What a responsible programmer will do is label the output.
Something like: "first differences of temperature readings".
If the reader of the data doesn't know what first differences are,
then such a reader won't make much sense of the data even if
you have some bizarre notation introduced for the zeros.  If he
reader does know what first differences are, I doubt the sign on
any zero values will be the least disconcerting.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

>>> To summarize:
>>>
>>> Point one: when used to simulate the continuous real numbers,
>>> floating point is *always* inexact.

>> I disagree.  There is a subset of the continuous real numbers that
>> can be exactly represented with a finite number of bits.

> It's a small of shaped subset of the rationals..  If and only if *ALL*
> your inputs, *ALL* your intermediate results, and *ALL* your results
> are members of that set can you say that the arithmetic is exact.

So, the difference between two exactly representable real numbers that
have exactly the same internal representation could be taken as an
exact zero, contrary to your claim that there is no such thing.

> And I've already said that several times.  So don't pretend you're
> making any points.  If *any* one of those points isn't true you're
> floating point is inexact..

You asked for an example of an exact zero.  I gave you one.  I have
now clarified the example so that it is resticted to only exactly
representable real numbers.  Are you now willing to accept that
there is such a thing as an exact zero, regardless of how rarely
it may occur in practice?

> It's comical that you focus on the *KNOWN* most error prone
> operation in all of floating point as youtr shining example
> of exactitude: subtract.

Don't try to put words into my mouth, Giles.  The issue has not been
"exactitude" in general, but rather a very specific issue, namely
your claim that there is no such thing as an exact zero.

> That shows such a complete lack
> of understanding of the issues as to be astonishing.

Rather ironic, because it shows your lack of understanding of
one issue I've been addressing, namely your claim that there is
no such thing as an exact zero.

>>> There is no "exact zero", or any other real number.

>> That is a semantic argument.  I provided one concept of an exact
>> zero.  I argue that it's a reasonable concept.  I've not seen anyone
>> offer a counter argument for it not being a reasonable concept.

> What you offered is in conflict with the definitions of floating
> point

How so?  Put up or shut up, as the saying goes.

> and comically with the common experience or users of
> such numbers.

It is not in conflict with my experience as a user of such numbers.
My experience is that there is a subset of real numbers that have
an exact representation with a finite number of bits.  Take two
variables that have the same exact representation of the same real
number and difference them.  I call that an exact zero, and as I
said earlier, zero should be in the subset of real numbers that
can be exactly represented in a finite number of bits.

> Subreact is the *shortest* path away from exactitude.

Irrelevant to the issue that we were discussing, which is your
claim that there is no such thing as an exact zero.

>>> Nor is there any reason zeros can't have signs.

>> Agreed.  But that doesn't mean that zeros must always have signs.

> But IEEE zeros always do.  Live with it.

I take it that you're opposed to progress, Giles?  I can just
imagine someone like you, after devising the 128 character ASCII
character set, being asked by some oriental person "What about
our lanugage, which has thousands of symbols?", responding with
"Live with it".

>>> Point two: on output the I/O implementation should always
>>> correctly display a minus sign if the number's internal sign
>>> bit was set.  This is true for all magnitudes of values being
>>> output.  Not to do so is irresponsible.

>> That avoids the more fundamental question of how to decide when
>> to set that internal sign bit.  [...]

> BUZZ.  The buzzer means you lose all your points and will have
> to settle for your parting gifts.

Classic pontification.

> This is point two now.

Irrelevant, given that I never said it wasn't, Giles.

> Yes, we are here avoiding the fundamental question you mention.

Correction:  you are avoiding the fundamental question.  Maybe I
should buzz the buzzer and claim that you lost all your points and
will have to settle for parting gifts.

> Within point two, it is *irrelevant* how the bit got set.

On the contrary, it's directly related to the issue.  Or should I
say that you'd be happy with the I/O library following strict
rules about the sign bit, even if how the sign bit gets set or
cleared was in error?

> The only issue is what the I/O library does with it.

I disagree.  There is also the issue of your claim that there
is no such thing as an exact zero.

> You keep avoiding that issue.

Others have dealt with the matter of what the standard says,
including members of the standards committee.  I see no need
to rehash what they've said.

> Which is strange since it's the principal subject of the
> thread (see the subject line).

I'm dealing with an issue that you brought up.  If you believe that
it's off-topic, then why did you bring it up?  If you believe that
it's on-topic, then what's the problem?

>>> Now, another contributor to this thread consistently confuses
>>> these separate points.

>> I'm not aware of any such contributor.

> You just did it!

Incorrect.

> You started in about a point one issue in response
> to point two!

Also incorrect.

> For the question about what the I/O implementation
> does, *HOW* the bit got set is *irrelevant*.

I disagree, for the reason given above.

> The I/O library doesn't
> know how the bit got set and therefore the decision can't be based
> on that information.

Are you saying that it's impossible for an implementation to produce
sufficient information for the I/O library to know how the bit got
set?  What was your reason for wanting interval arithmetic?

>> On what basis do you claim that differences of identically
>> represented numbers are not exact zeros?

> By definition.

Whose definition?  Yours?

> The differences to two inexactly known quantities can't be exact.

But there is a subset of real numbers that can be represented
exactly.  In particular, zero should be a member of that subset.

> Since the purpose of floaing point is approximation
> of continuous real numbers, they can *never* be regarded as exact.

In general, but there is that subset.

> The common observation of the programming community that
> subtraction of similar values leaves essentially no significance
> ought to be a clue.  That's an empirical observation about the
> result of using float.  It most common to regard differences
> resulting with zero with particular dismay - not only is the
> relative error in the result *infinite*, the absolute error can't
> even be estimated (not even to within a few orders of magnitude)
> from just the value itself.  Zero, as a difference, usually carries
> no useful information at all.

Are you trying to use that to support your claim that there is no
such thing as an exact zero?

> By the way, the IEEE standard states explicitly how the sign bit
> gets set in *all* operations except the one case where it makes no
> difference (at least, not to anyone that understands what floating
> point is doing).

What about the Fortran standard?

> The only ambiguity is in your mind.

What alleged ambiguity?

James Giles writes:

> ....

>>> But, the sign is present like it or not.

>> Only because you insist that a sign must be present.  As I noted
>> in another posting, the situation is more complex than that.

> No.  The sign bit exists whether you like it or not because the
> IEEE standard says so.  It would still say so whether I insist
> or not.  There's a bit in each floating point value representing
> the sign.  That bit is always present.  It has one of two values.
> That follows from the fact that it's a bit.  Nothing you've said
> in any thread in any newsgroup at any time in the past or
> even the future will make it more or less complex than
> that.  It's actually pretty simple.

But we're talking about the Fortran standard here, not the IEEE
standard.

>>> No sign means the same as a plus sign.

>> Doesn't have to be that way.  Sure, in a binary representation, if
>> you allocate only a single bit to the sign, then you can have only
>> two states.  But we're talking about the external representation,
>> where in theory we can have many different characters, including
>> minus, plus, blank, greater than, less than, and even plus-minus.

> And, you keep failing to specify what magic you think the I/O
> library is going to use to infer more than one bit of information
> from the one bit that's present.

Wasn't "interval arithmetic" your magic, Giles?

> The sign has two states.

When limited to one bit.  Just like the character set has 256 states
when limited to 8 bits.  But now we have double byte character sets.
What's to prevent some new generation of computer and compiler to come
along with interval arithmetic and multi-bit sign?

> Using a different convention for zero magnitude values still
> leaves the necessity to report which of those two states the
> sign bit was in.

Suppose the convention was changed such that an extra bit was
allocated for the sign?  We've gone from four-bit processors to
eight-bit processors, to sixteen-bit processors, to 32-bit
processors, to 64-bit processors.  How long before we have
128-bit processors and enough bits for a multi-bit sign?  Some
compilers already support quad precision.  Wouldn't necessarily
need 128-bit CPUs.

> And using said different notation just complicates
> the language for no purpose,  The present convention of using
> a minus sign if the sign bit is set, and a plus sign (or nothing at
> all)  if the sign bit is clear answers admirably.  It tells the whole
> story.

How can you say that when a single bit offers only two states, but
there are more than two possible outcomes?

> At least all of the story that the I/O library knows without
> arbitrarily making up information out of the air!

There's more to the matter than just the I/O library.
 
>>> That includes a correct
>>> indication of the sign of the value being printed.  This is a
>>> very simple concept: the I/O library can't discern the meaning
>>> of the value or whether the sign is meaningful or not.

>> Precisely.  So in your thermometer example, where the sign isn't
>> meaningful, the processor doesn't know that, thus it has a fifty
>> percent chance of getting it wrong by being forced to display a
>> sign.

> And it has a 100% chance of being wrong if it claims that the
> answer is *exact* zero.

But you claimed that there is no such thing.  Although I disagree,
that doesn't mean I believe the thermometer example represents a
case of an exact zero.

> That's not an improvement.

Irrelevant, given that I never said it would be an improvement.

> The existing implementation is writing all zero digits for the
> value already.  To anyone with an understanding of float, that
> means the value (the result of a subtract), by itself, has no
> significance at all, much less does the sign mean anything.

So a single sign bit isn't sufficient.

> You keep claiming that the answer is being written wrong.

Incorrect.  I said that the answer has a fifty percent chance
of being wrong.

> It isn't, you're just interpreting it wrong.

Ironically, you interpreted my statement wrong.

> If you insist on
> interpreting a notational convention differently than it was
> intended, you'll continue to make mistakes.

Unfortunately, the compiler doesn't spit out the intention of
notational conventions along with the numerical results.  Do
you have any Fortran compiler documentation that explains how
signs are handled?

> As I said, you
> can insist that when I say "tea" it doesn't mean a beverage:
> you'll usually be wrong.

Irrelevant, given that I haven't done so.

>> The user is frequently different from the programmer.  It's up
>> to the programmer to supply sufficient information so that the
>> user has what he needs.

> Then by gosh the programmer can write a string of plusses and
> minuses or draw a picture of a clown if (s)he wants.

Imagine that, extra bits to work with.  Do the propagation of
error computation, show what the uncertainty in the result is,
and then you don't have to mess with the interpretation of a
sign.  I guess that's "magic" to you.

> Just don't
> lie to the later reader by pretending it to be the actual report of
> the actual calculation.  Such an actual report can already be made
> clearly by the output convention usually recommended.

I disagree.  A single bit has only two states, but there are more
than two possible outcomes.  Doing a propagation of error
computation carries far more information.

> What a responsible programmer will do is label the output.
> Something like: "first differences of temperature readings".

You think that's more responsible than a full propagation of
error computation?  Of course, you have to do the computation
properly.  Too often quantization noise is ignored.

> If the reader of the data doesn't know what first differences are,
> then such a reader won't make much sense of the data even if
> you have some bizarre notation introduced for the zeros.  If he
> reader does know what first differences are, I doubt the sign on
> any zero values will be the least disconcerting.

Are you using that to try and justify that only two states are
sufficient for a sign?

tholen@antispam.ham wrote:
> James Giles writes:
....
>> It's a small of shaped subset of the rationals..  If and only if
>> *ALL* your inputs, *ALL* your intermediate results, and *ALL* your
>> results are members of that set can you say that the arithmetic is
>> exact.
>
> So, the difference between two exactly representable real numbers that
> have exactly the same internal representation could be taken as an
> exact zero, contrary to your claim that there is no such thing.

I said there isn't such a thing when using float to simulate continuous
reals.  In the above, the calculation is obviously defined on some
subset of the rationals.  I was the first in this thread to state explicitly
that using float for something *other* than simulating continuous reals
could give exact results.

You're grasping at straws if you think that changing the basis of the
discussion to exclude continuous reals has any relevance to your
previous mistakes.  You've maintained that zeros are exact even
when dealing with simulated continuous reals (the very purpose
of the temperature example was to make *sure* the values involved
were definitely known in advance to be inexact).  Your *definition*
of "exact" disregard the provenance of the values involved.

>> It's comical that you focus on the *KNOWN* most error prone
>> operation in all of floating point as youtr shining example
>> of exactitude: subtract.
>
> Don't try to put words into my mouth, Giles.  The issue has not been
> "exactitude" in general, but rather a very specific issue, namely
> your claim that there is no such thing as an exact zero.

The issue has *always* been exactitude in general.  If you meant
any other kind of exactitude you should have said so at the outset.
Words are usually considered to have their usual meaning in
conversations unless you explicitly identify some novel meaning.

But, in any case, the temperature example is a case where you've
claimed exactitude when it's not present.  And it's a specific case,
not general at all.

>> What you offered is in conflict with the definitions of floating
>> point
>
> How so?  Put up or shut up, as the saying goes.

I have several times.  Floating point is intended as a computational
simulation of continuous reals.  That's it's stated purpose.  For that
purpose, zeros have no exactitude (nor do any other values).

>> But IEEE zeros always do.  Live with it.
>
> I take it that you're opposed to progress, Giles?  I can just
> imagine someone like you, after devising the 128 character ASCII
> character set, being asked by some oriental person "What about
> our lanugage, which has thousands of symbols?", responding with
> "Live with it".

No, I *like* progress.  I like it alot. That's why I embrace signed
zeros.  It's also why I'd oppose the unnecessay complexity of all
kinds of arcane (and mostly mystical) ways of reporting the
result of float operations in I/O.  If you care so much you can
write your own filter to use internal I/O and to get the data
and then delete the signs you don't like.  I doubt your colleagues,
customers, or employers will agree with the unnecessary work.

....
> I'm dealing with an issue that you brought up.  [...]

No, [a third party] brought it up.  (see below)

> [...] If you believe that
> it's off-topic, [...]

I do believe it's off topic.  I didn't bring it up.  I've tried to
abandon it. Any discussion in response to my (point two) in
the summary should not mention it at all.  Why do you think
I separated the issues in the first place?  I wanted to abandon
the irrelevant mystical discussion about exactitude.  I've
obviously trampled on something you believe with religious
fervor -- as if God himself invented numbers and it was
blasphemy to put a sign on zero or doubt its exactitude.
Well, I though it was a bogus argument when it was introduced
(not you, another person actually wanted yet another backward
step in computing by adding a third zero to the internal
representation to account for "actual zero").  I still think it's
a bogus argument.  I responded to what is obviously a very
bad idea.  Yes, I shouldn't have.  Trampling on someone's
religion is always a mistake.  There's not even a remote
possibility that IEEE or anyone else will act on such a poorly
founded suggestion as to add yet another way to represent zero.
So I had no need to mention it.  I've paid.  You inquisitors will
insure I continue to pay.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
> James Giles writes:
....
>> And, you keep failing to specify what magic you think the I/O
>> library is going to use to infer more than one bit of information
>> from the one bit that's present.
>
> Wasn't "interval arithmetic" your magic, Giles?

Interval arithmetic carries *a* *lot* more information.
Yes, if you provide the I/O library with a new data type
(intervals) the I/O thenhas something else to work with.
It's not magic, it's well defined, hardnosed, pragmatic
I/O.

You keep recommending that the Fortran I/O library do
something different with just plain float.  What?  You keep
failing to specify.

>> The sign has two states.
>
> When limited to one bit.  Just like the character set has 256 states
> when limited to 8 bits.  But now we have double byte character sets.
> What's to prevent some new generation of computer and compiler to come
> along with interval arithmetic and multi-bit sign?

Design it and we'll talk.  But if it's filled with unnecessary
complexity just to deal with you mystical belief that the
difference of inexact values is exact, forget it.  No one
will buy a backward step as progress.  Mysticism is a
dark age phenomenon.

Besides, I elided it above, but weren't you the one that
just said:

> But we're talking about the Fortran standard here, not the IEEE
> standard.

Surely some hypothetical multi-bit sign form is even more
off topic than IEEE.  Your multi-sign replacement hasn't
even reached the design stage yet.  IEEE is nearly universal.
It's certainly ubiquitous.

>> And using said different notation just complicates
>> the language for no purpose,  The present convention of using
>> a minus sign if the sign bit is set, and a plus sign (or nothing at
>> all)  if the sign bit is clear answers admirably.  It tells the whole
>> story.
>
> How can you say that when a single bit offers only two states, but
> there are more than two possible outcomes?

I say it because there aren't more than two *IMPORTANT*
outcomes.  Even those two are sometimes unimportant.  I say
it because I am self consistent - I oppose unnecessary complexity
in computing environments.

>> At least all of the story that the I/O library knows without
>> arbitrarily making up information out of the air!
>
> There's more to the matter than just the I/O library.

As you've reminded me in three messages now, none of
those are on topic in this thread.  What is Fortran I/O to
do with floating point output *NOW*?

>> And it has a 100% chance of being wrong if it claims that the
>> answer is *exact* zero.
>
> But you claimed that there is no such thing.  [...]

So that makes it even more wrong for the I/O library to claim it!

> [...]                                Although I disagree,
> that doesn't mean I believe the thermometer example represents a
> case of an exact zero.

You said it was before.  You *defined* exact zero as the difference
of two values with identical internal represenations.  You made no
allowances for the provenance of the numbers involved.  Your own
words require that you believe that the thermometer example
represents a case of exact zero.

>> That's not an improvement.
>
> Irrelevant, given that I never said it would be an improvement.

Good, now we're getting somewhere.  Can we now stop talking
about changing the admirable rule Fortran already has for writing
zeros?

>> The existing implementation is writing all zero digits for the
>> value already.  To anyone with an understanding of float, that
>> means the value (the result of a subtract), by itself, has no
>> significance at all, much less does the sign mean anything.
>
> So a single sign bit isn't sufficient.

For a quantity that means nothing, it's overspecified.  That means
it's *more* than sufficient.  There's certainly no need for even
more.

> Unfortunately, the compiler doesn't spit out the intention of
> notational conventions along with the numerical results.  Do
> you have any Fortran compiler documentation that explains how
> signs are handled?

The standard is pretty precise.  Taken with the specification
of whatever float representatin you use, it's conclusive.

>> Then by gosh the programmer can write a string of plusses and
>> minuses or draw a picture of a clown if (s)he wants.
>
> Imagine that, extra bits to work with.  [...]

Extra bits on output you mean.  No extra bits on input (to the
I/O library) though.  This extra noise warns the user of a bogus
problem in a bogus way.  I can't prevent a bad programmer from
doing it.  I can't prevent all sorts of counterproductive behavior.

> [...]                       Do the propagation of
> error computation, show what the uncertainty in the result is, [...]

Not unless the I/O library is given that information.  NO?  You
didn't pass that data?  You didn't say *specifically* (as I keep
asking) what you expect the I/O library to do?  No, you didn't.

And interestingly, if you *do* a formal error propagation
analysis, the existing rules for handling signs (even of zeros)
are sufficient to clearly report the results.

> I disagree.  A single bit has only two states, but there are more
> than two possible outcomes.  Doing a propagation of error
> computation carries far more information.

Then *DO* *IT*.  You mentioned none of this before!  Your
previous claims were entirely based on just the normal float
results.  This is like the bad mystery writer that tells a long
story with lots of clues concerning central characters and then
reveals the crime was committed by a stranger that was just caught
in the next state.  What a gyp.  Ringing in a whole different
issue never mentioned before. and so late in the game.

>> What a responsible programmer will do is label the output.
>> Something like: "first differences of temperature readings".
>
> You think that's more responsible than a full propagation of
> error computation?  Of course, you have to do the computation
> properly.  Too often quantization noise is ignored.

In this simple case, I think the savvy reader knows what the
error was without such expensive analysis.  The source of
error is the reliability of the thermometer and the fact that
it discretized the data.  The only operation is a subtract.
No, a *really* complex, slow method is like killing a fly
with an atomic bomb.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

glen herrmannsfeldt writes:

> James Giles wrote:

>> tholen@antispam.ham wrote:

> (snip)

>>> That avoids the more fundamental question of how to decide when
>>> to set that internal sign bit.  [...]

>> BUZZ.  The buzzer means you lose all your points and will have
>> to settle for your parting gifts.  This is point two now.  Yes, we
>> are here avoiding the fundamental question you mention.  Within
>> point two, it is *irrelevant* how the bit got set.  The only issue
>> is what the I/O library does with it.  You keep avoiding that
>> issue.  Which is strange since it's the principal subject of the
>> thread (see the subject line).

> I have been in these discussions before, and some times thought
> that a license should be required to use floating point arithmetic.
> So many mistakes can be made by people believing what they want
> to believe, and not what the logic actually does.
>
> In this case, I think tholen's license should be revoked.

Fortunately, what you think is irrelevant, glen.  The facts are
relevant, and you haven't presented any fact that I don't know
how to use floating point arithmetic.

James Giles wrote:
> tholen@antispam.ham wrote:

(snip)

>>That avoids the more fundamental question of how to decide when
>>to set that internal sign bit.  [...]

> BUZZ.  The buzzer means you lose all your points and will have
> to settle for your parting gifts.  This is point two now.  Yes, we
> are here avoiding the fundamental question you mention.  Within
> point two, it is *irrelevant* how the bit got set.  The only issue
> is what the I/O library does with it.  You keep avoiding that
> issue.  Which is strange since it's the principal subject of the
> thread (see the subject line).

I have been in these discussions before, and some times thought
that a license should be required to use floating point arithmetic.
So many mistakes can be made by people believing what they want
to believe, and not what the logic actually does.

In this case, I think tholen's license should be revoked.

-- glen

James Giles wrote:
> tholen@antispam.ham wrote:
> 
>>James Giles writes:
> 
> ...
> 
>>>But, the sign is present like it or not.
>>
>>Only because you insist that a sign must be present.  As I noted
>>in another posting, the situation is more complex than that.
> 
> 
> No.  The sign bit exists whether you like it or not because the
> IEEE standard says so.  It would still say so whether I insist
> or not.  There's a bit in each floating point value representing
> the sign.  That bit is always present.  It has one of two values.
> That follows from the fact that it's a bit.  Nothing you've said
> in any thread in any newsgroup at any time in the past or
> even the future will make it more or less complex than
> that.  It's actually pretty simple.

Theoretically speaking, whether there is a bit reserved for a sign could 
be irrelevant.  It could be defined to be "reserved" when the value is 
"exactly 0.0".  There's no reason why it must always have the same 
definition.  I'm not saying it would ever be or should be implemented 
that way.  All this hurts my head though.  So long as I can control 
whether the sometimes superfluous +/- is displayed for 0.0 on I/O 
transfers (even when it's actually a "-0.0" situtation, wonderful.

> 
> 
>>>No sign means the same as a plus sign.
>>
>>Doesn't have to be that way.  Sure, in a binary representation, if
>>you allocate only a single bit to the sign, then you can have only
>>two states.  But we're talking about the external representation,
>>where in theory we can have many different characters, including
>>minus, plus, blank, greater than, less than, and even plus-minus.
> 
> 
> And, you keep failing to specify what magic you think the I/O
> library is going to use to infer more than one bit of information
> from the one bit that's present.  The sign has two states.
> 
> Using a different convention for zero magnitude values still
> leaves the necessity to report which of those two states the
> sign bit was in.  And using said different notation just complicates
> the language for no purpose,  The present convention of using
> a minus sign if the sign bit is set, and a plus sign (or nothing at
> all)  if the sign bit is clear answers admirably.  It tells the whole
> story.  At least all of the story that the I/O library knows without
> arbitrarily making up information out of the air!
> 
> 
>>>That includes a correct
>>>indication of the sign of the value being printed.  This is a
>>>very simple concept: the I/O library can't discern the meaning
>>>of the value or whether the sign is meaningful or not.
>>
>>Precisely.  So in your thermometer example, where the sign isn't
>>meaningful, the processor doesn't know that, thus it has a fifty
>>percent chance of getting it wrong by being forced to display a
>>sign.
> 
> 
> And it has a 100% chance of being wrong if it claims that the
> answer is *exact* zero.  That's not an improvement.
> 
> The existing implementation is writing all zero digits for the
> value already.  To anyone with an understanding of float, that
> means the value (the result of a subtract), by itself, has no
> significance at all, much less does the sign mean anything.
> 
> You keep claiming that the answer is being written wrong.
> It isn't, you're just interpreting it wrong.  If you insist on
> interpreting a notational convention differently than it was
> intended, you'll continue to make mistakes.  As I said, you
> can insist that when I say "tea" it doesn't mean a beverage:
> you'll usually be wrong.
> 
> 
>>The user is frequently different from the programmer.  It's up
>>to the programmer to supply sufficient information so that the
>>user has what he needs.
> 
> 
> Then by gosh the programmer can write a string of plusses and
> minuses or draw a picture of a clown if (s)he wants.  Just don't
> lie to the later reader by pretending it to be the actual report of
> the actual calculation.  Such an actual report can already be made
> clearly by the output convention usually recommended.
> 
> What a responsible programmer will do is label the output.
> Something like: "first differences of temperature readings".
> If the reader of the data doesn't know what first differences are,
> then such a reader won't make much sense of the data even if
> you have some bizarre notation introduced for the zeros.  If he
> reader does know what first differences are, I doubt the sign on
> any zero values will be the least disconcerting.
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

glen herrmannsfeldt wrote:
....
> There are many interesting things that could be done if one
> wanted to do them.  Somewhat less than full interval
> arithmetic, one could keep the number of bits or digits of
> precision along with the value.  One I previously suggested,
> one could have a bit indicating a multiple of pi so that
> exact multiples of pi could be used with trigonometric functions.
> One could also have different zeros, including more or less
> exact zeros.

And of course there are many genuinely uninteresting things
one might do as well.  It's maybe of interest that many of the
features above might belong on both lists.  Significance
arithmetic is a case in point.  It turns out that it's probably
even more pessimistic than interval arithmetic.  This is
because it actually disregards information rather than
keeping two (slightly different) copies.  With interval
arithmetic it is often possible to reduce the interval because
of semantic knowledge you have of the algorithm that the
compiler doesn't have.  (For example, some iterative
algorithms can't possibly increase the error in the result,
but intervals sometimes increase in width anyway.  You
know this fact and can give a *better* result by computing
the intersection of the input interval with the output interval.
Viola!  A narrower interval results after all.  Ask Dr.
Warnock and others for more details.  I'm a novice on
the subject.)

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

(snip)

> Surely some hypothetical multi-bit sign form is even more
> off topic than IEEE.  Your multi-sign replacement hasn't
> even reached the design stage yet.  IEEE is nearly universal.
> It's certainly ubiquitous.

This is reminding me of a talk I went to by Kahan many years
ago.  It would have been around the time of the IEEE standard.
He was mentioning the problem of precision loss in subtraction,
and that no processors had a way to handle the problem.
So I ask about S/370, and the significance exception.
He seemed a little surprised, never having been asked about
it before.  It only applied to complete loss of significance
(subtracting identical values) and is pretty much always
disabled.  (Especially since floating point registers
are usually cleared by subtraction.)

There are many interesting things that could be done if one
wanted to do them.  Somewhat less than full interval
arithmetic, one could keep the number of bits or digits of
precision along with the value.  One I previously suggested,
one could have a bit indicating a multiple of pi so that
exact multiples of pi could be used with trigonometric functions.
One could also have different zeros, including more or less
exact zeros.

-- glen

Gary Scott wrote:
> [...] All this hurts my head though.  So long as I
> can control whether the sometimes superfluous +/- is displayed for
> 0.0 on I/O transfers (even when it's actually a "-0.0" situtation,
> wonderful.

What hurts my head it the idea that someone might supress
useful information without telling me.  Since there are cases
where the sign of zero it's *very* significant, I'd prefer to make
up my own mind.

I still stand by my original statement in this thread:

> Just my opinion, but I'd recommend that you print the minus sign.
> I don't even see a need to have an option to turn it off.  [...]

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> 
>>[...] All this hurts my head though.  So long as I
>>can control whether the sometimes superfluous +/- is displayed for
>>0.0 on I/O transfers (even when it's actually a "-0.0" situtation,
>>wonderful.
> 
> 
> What hurts my head it the idea that someone might supress
> useful information without telling me.  Since there are cases
> where the sign of zero it's *very* significant, I'd prefer to make
> up my own mind.
> 
> I still stand by my original statement in this thread:
> 
> 
>>Just my opinion, but I'd recommend that you print the minus sign.
>>I don't even see a need to have an option to turn it off.  [...]

If I know the range value (say 0.0 to 9.9) that I'm printing must/will 
always fit in 3 spaces on an unprotected field on a display (0.0), I 
don't want the minus sign causing an unnecessary overflow because of 
insufficient space.  I'll allow you the option to include it if you give 
me the option to exclude it.  I don't care what the default is 
(personally, others might).

> 
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
>...
> If I know the range value (say 0.0 to 9.9) that I'm printing must/will
> always fit in 3 spaces on an unprotected field on a display (0.0), ...

Then print ABS(X).  That certainly deals with any sign you might
get.  (It might also eliminate a useful sanity check on your data too.)
Besides, I'm absolutely sure that negative zero will fit in an F3.1
field. You won't get three asterisks, you'll get (-.0).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> 
>>...
>>If I know the range value (say 0.0 to 9.9) that I'm printing must/will
>>always fit in 3 spaces on an unprotected field on a display (0.0), ...
> 
> 
> Then print ABS(X).  That certainly deals with any sign you might
> get.  (It might also eliminate a useful sanity check on your data too.)
> Besides, I'm absolutely sure that negative zero will fit in an F3.1
> field. You won't get three asterisks, you'll get (-.0).
> 
Then I'd be forced to write to a character variable and manipulate it to 
get a proper display.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
> James Giles wrote:
....
>> Then print ABS(X).  That certainly deals with any sign you might
>> get.  (It might also eliminate a useful sanity check on your data
>> too.) Besides, I'm absolutely sure that negative zero will fit in an
>> F3.1 field. You won't get three asterisks, you'll get (-.0).
>>
> Then I'd be forced to write to a character variable and manipulate it
> to get a proper display.

Not if you used ABS().  But, what about it is improper?
Looks normal to me.  There's nothing illicit (or even a
little naughty) about it.  No rebellion against settled
authority.  No violation of any religious precept (unless
it's some numerological dogma).  What's improper?
The values will still read back in correctly - even in
non-Fortran languages.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ....

>>> It's a small of shaped subset of the rationals..  If and only if
>>> *ALL* your inputs, *ALL* your intermediate results, and *ALL* your
>>> results are members of that set can you say that the arithmetic is
>>> exact.

>> So, the difference between two exactly representable real numbers that
>> have exactly the same internal representation could be taken as an
>> exact zero, contrary to your claim that there is no such thing.

> I said there isn't such a thing when using float to simulate continuous
> reals.

And I noted that there is a subset of continuous reals that can be
represented exactly using a finite number of bits.  Zero should be
a member of that subset.

> In the above, the calculation is obviously defined on some
> subset of the rationals.  I was the first in this thread to state explicitly
> that using float for something *other* than simulating continuous reals
> could give exact results.

Then it could give an exact zero, no?

> You're grasping at straws if you think that changing the basis of the
> discussion to exclude continuous reals has any relevance to your
> previous mistakes.

What alleged previous mistakes?

> You've maintained that zeros are exact even
> when dealing with simulated continuous reals

Where did I allegedly say that?  I've not claimed that all such
zeros are exact.  A subset of such zeros could be exact, according
to the definition I provided.

> (the very purpose
> of the temperature example was to make *sure* the values involved
> were definitely known in advance to be inexact).

But my definition of an exact zero was made before you offered
your temperature example:  the difference of two identical
internal representations.  That way we get the same answer from

   L = X == Y

and

   L = (Y - X) == 0.0

> Your *definition*
> of "exact" disregard the provenance of the values involved.

How so?

>>> It's comical that you focus on the *KNOWN* most error prone
>>> operation in all of floating point as youtr shining example
>>> of exactitude: subtract.

>> Don't try to put words into my mouth, Giles.  The issue has not been
>> "exactitude" in general, but rather a very specific issue, namely
>> your claim that there is no such thing as an exact zero.

> The issue has *always* been exactitude in general.

Balderdash.  The original issue was whether the default behavior in
gfortran should be to put a minus sign on a zero when the sign bit
is set.  The original item to which I responded was your statement
"So the real problem is that people tend to think that programs
can represent, manipulate, or produce matephysically perfect 'exact'
zeros in the first place."  Note the specific reference to an
exact zero, not exactitude in general.

> If you meant
> any other kind of exactitude you should have said so at the outset.

It should have been obvious from my response to your statement that
I was dealing with the concept of an exact zero.

> Words are usually considered to have their usual meaning in
> conversations unless you explicitly identify some novel meaning.

Irrelevant, given that I never claimed otherwise.  Now, is there a
usualy meaning of "exact zero"?  If so, then please tell me what it
is.  If not, then we need to adopt a meaning.  I gave you my concept
of an exact zero.  What's yours?  Let's at least agree on a definition
before continuing.

> But, in any case, the temperature example is a case where you've
> claimed exactitude when it's not present.

On the contrary, I've specifically stated that one doesn't know
the correct sign to attach to the zero in that case.  How could
you possibly misinterpret that as a claim of exactitude?

> And it's a specific case, not general at all.

Also irrelevant, because I've not claimed otherwise.

>>> What you offered is in conflict with the definitions of floating
>>> point

>> How so?  Put up or shut up, as the saying goes.

> I have several times.  Floating point is intended as a computational
> simulation of continuous reals.  That's it's stated purpose.

And the implementation of floating point allows for a subset of
continuous reals to be represented exactly.

> For that purpose, zeros have no exactitude (nor do any other values).

I disagree.  There is a subset of continuous reals that can be
represented exactly using a finite number of bits.

>>> But IEEE zeros always do.  Live with it.

>> I take it that you're opposed to progress, Giles?  I can just
>> imagine someone like you, after devising the 128 character ASCII
>> character set, being asked by some oriental person "What about
>> our lanugage, which has thousands of symbols?", responding with
>> "Live with it".

> No, I *like* progress.  I like it alot. That's why I embrace signed
> zeros.

So why not encourage the next step rather than saying "live with it"?

> It's also why I'd oppose the unnecessay complexity of all
> kinds of arcane (and mostly mystical) ways of reporting the
> result of float operations in I/O.  If you care so much you can
> write your own filter to use internal I/O and to get the data
> and then delete the signs you don't like.  I doubt your colleagues,
> customers, or employers will agree with the unnecessary work.

But I haven't proposed to do any unnecessary work, Giles.

> ....

>> I'm dealing with an issue that you brought up.  [...]

> No, [a third party] brought it up.  (see below)

My response was to you.  Your response was to Ron Shepard,
who noted that there is no way to represent three zeros,
namely -0.0, 0.0, and +0.0 using the sign bit, which can
have only two values.  In your response, you first said that
"In IEEE floating point, there are two different approximations
to zero.  The concept of *exactly* zero is *equally* represented
by either of those approximations (hence, the two compare equal
to each other)."  But then you later said "So the real problem
is that people tend to think that programs can represent,
manipulate, or produce matephysically perfect 'exact' zeros
in the first place."  So first you talk about exactly zero,
and then you call it a problem to think about an exact zero.
Isn't that inconsistent?

>> [...] If you believe that
>> it's off-topic, [...]

> I do believe it's off topic.  I didn't bring it up.

Who allegedly brought up the matter of exact zero before you?
Ron Shepard referred to an absolute zero, but the whole
concept of a sign on the zero requires the concept of an
absolute zero, namely the dividing line between where you
use a minus sign and where you use a plus sign or blank.

> I've tried to abandon it.

By continuing to post responses about it?

> Any discussion in response to my (point two) in
> the summary should not mention it at all.  Why do you think
> I separated the issues in the first place?

The issue I responded to is the one you made five days ago,
namely the exact zero.  

> I wanted to abandon
> the irrelevant mystical discussion about exactitude.  I've
> obviously trampled on something you believe with religious
> fervor -- as if God himself invented numbers and it was
> blasphemy to put a sign on zero or doubt its exactitude.

I suggest you go back and reread what I've written, because
you've either misread something or have confused me with
somebody else, because I have no such religious fervor.

> Well, I though it was a bogus argument when it was introduced
> (not you, another person actually wanted yet another backward
> step in computing by adding a third zero to the internal
> representation to account for "actual zero").  I still think it's
> a bogus argument.  I responded to what is obviously a very
> bad idea.

So, you believe that computational mathematics needs nothing more
than just two kinds of zero?

> Yes, I shouldn't have.  Trampling on someone's
> religion is always a mistake.

You're erroneously presupposing that some religion is involved
here.  If you still believe otherwise, then perhaps you should
think about your own religion being involved as well.

> There's not even a remote
> possibility that IEEE or anyone else will act on such a poorly
> founded suggestion as to add yet another way to represent zero.
> So I had no need to mention it.

But you did anyway.

> I've paid.  You inquisitors will
> insure I continue to pay.

Interesting the way you view the discussion.  We're the "inquisitors",
and you're not?

James Giles wrote:
(snip)

> Not if you used ABS().  But, what about it is improper?
> Looks normal to me.  There's nothing illicit (or even a
> little naughty) about it.  No rebellion against settled
> authority.  No violation of any religious precept (unless
> it's some numerological dogma).  What's improper?
> The values will still read back in correctly - even in
> non-Fortran languages.

For F2.1, though, there is no room for a sign.
(Unless you give -. as output.)


That should be pretty rare, though.

-- glen

Still completely ignoring the topic above (the subject line)
tholen@antispam.ham wrote:
....
>> You've maintained that zeros are exact even
>> when dealing with simulated continuous reals
>
> Where did I allegedly say that?  I've not claimed that all such
> zeros are exact.  A subset of such zeros could be exact, according
> to the definition I provided.

Why do people insist on misrepresenting their own prior statements
in usenet newsgroups?  The group is archived.  You said nothing
about subsets in your definition.  Your definition was stated
without qualificaton.  Look for yourself (most others don't
need to, they know I'm right).

>> (the very purpose
>> of the temperature example was to make *sure* the values involved
>> were definitely known in advance to be inexact).
>
> But my definition of an exact zero was made before you offered
> your temperature example:  the difference of two identical
> internal representations.  [...]

And you repeated it several times, even in direct reference to that
very example.  Look for yourself.  Anyone that's forgotten it can check
too.  The group is archived.

....
Yada yada...

Why not answer the question put to you?  What do you recommend
Fortran do *now*.  Not after some hypothetical change to the number
system - now.   Not after you provide your never-before-mentioned
error propagation analysis - now.  Answer the question.

>>> No, I *like* progress.  I like it alot. That's why I embrace signed
>> zeros.
>
> So why not encourage the next step rather than saying "live with it"?

Your advice about the next step is counterproductive, expensive,
and without merit.  Suggest an advance and you'll get interest.

> But I haven't proposed to do any unnecessary work, Giles.

So far you haven't proposed that *you* do any work at all.
You place it on others to provide you with unnecessarily complex
multiply signed floats.  You insist on some (yet to be specified)
way of deciding within the I/O library what arcane new
ways to display zeros that avoid signs (or not?  you haven't
specified, you just keep refusing).  But  *you're* not acting
to explicitly work on those "solutions".

Of course, there is no problem, so no "solutions" need be
found anyway.  Probably just as well you're so intentially vague.

>> [...]              but the whole
> concept of a sign on the zero requires the concept of an
> absolute zero, [...]

Now that's funny!!!

> So, you believe that computational mathematics needs nothing more
> than just two kinds of zero?

It often doesn't even need two.  It certainly needs no more.
At least not based on anything you've said.  Everything
you've mentioned as problems are actually better without
your suggested changes (and even the ones you're refused to
suggest).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> 
>>James Giles wrote:
> 
> ...
> 
>>>Then print ABS(X).  That certainly deals with any sign you might
>>>get.  (It might also eliminate a useful sanity check on your data
>>>too.) Besides, I'm absolutely sure that negative zero will fit in an
>>>F3.1 field. You won't get three asterisks, you'll get (-.0).
>>>
>>
>>Then I'd be forced to write to a character variable and manipulate it
>>to get a proper display.
> 
> 
> Not if you used ABS().  But, what about it is improper?
> Looks normal to me.  There's nothing illicit (or even a
> little naughty) about it.  No rebellion against settled
> authority.  No violation of any religious precept (unless
> it's some numerological dogma).  What's improper?
> The values will still read back in correctly - even in
> non-Fortran languages.
> 

For example, what if my specification for how the display is to appear 
(defined by some nebulous system designer somewhere) requires 
specifically that the display value be displayed as 0.0 through 9.9?  I 
don't have a choice in how I display the value, I'm to implement as the 
system designer said it should be implemented.  If there is a reason to 
detect negative zero, I can do that separately and pop up a message box 
that says some sort of unexpected error happened, perhaps a DMA 
peripheral device set a bit it wasn't supposed to.  Or it may be a don't 
care for this particular application that the sign bit isn't set.


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

James Giles writes:

> ....

>>> And, you keep failing to specify what magic you think the I/O
>>> library is going to use to infer more than one bit of information
>>> from the one bit that's present.

>> Wasn't "interval arithmetic" your magic, Giles?

> Interval arithmetic carries *a* *lot* more information.

There's your "magic".

> Yes, if you provide the I/O library with a new data type
> (intervals) the I/O thenhas something else to work with.
> It's not magic, it's well defined, hardnosed, pragmatic
> I/O.

So, I answer your question about the magic by referring to something
you brought up, and now suddenly it's not magic anymore.  Why am I
not surprised?

> You keep recommending that the Fortran I/O library do
> something different with just plain float.

Where did I make such a recommendation, Giles?

> What?  You keep failing to specify.

Why should I?  That was never the issue to which I responded.  Rather,
I responded to the issue of an "exact" zero.  I specified my concept
of an exact zero.

>>> The sign has two states.

>> When limited to one bit.  Just like the character set has 256 states
>> when limited to 8 bits.  But now we have double byte character sets.
>> What's to prevent some new generation of computer and compiler to come
>> along with interval arithmetic and multi-bit sign?

> Design it and we'll talk.  But if it's filled with unnecessary
> complexity just to deal with you mystical belief that the
> difference of inexact values is exact, forget it.

The key word here is "if".  I have no need to do such a thing,
because I don't believe that the difference of inexact values
is exact.  I do believe that the difference of two identical
internal representations is a reasonable concept of an "exact"
zero, however, in the sense that there is no way to decide
whether a plus or minus sign should be attached to that zero.

> No one will buy a backward step as progress.  Mysticism is a
> dark age phenomenon.

Irrelevant, given that I haven't proposed any backward step.

> Besides, I elided it above, but weren't you the one that
> just said:

>> But we're talking about the Fortran standard here, not the IEEE
>> standard.

> Surely some hypothetical multi-bit sign form is even more
> off topic than IEEE.  Your multi-sign replacement hasn't
> even reached the design stage yet.  IEEE is nearly universal.
> It's certainly ubiquitous.

Interval arithmetic isn't universal or ubiquitous, yet you brought it
up.  Obviously you don't have a problem with bringing up things that
aren't universal or ubiquitous, so you shouldn't have a problem when
somebody else does likewise.

>>> And using said different notation just complicates
>>> the language for no purpose,  The present convention of using
>>> a minus sign if the sign bit is set, and a plus sign (or nothing at
>>> all)  if the sign bit is clear answers admirably.  It tells the whole
>>> story.

>> How can you say that when a single bit offers only two states, but
>> there are more than two possible outcomes?

> I say it because there aren't more than two *IMPORTANT*
> outcomes.

Just because a third one isn't important to you doesn't mean that it
can't be important to someone else.

> Even those two are sometimes unimportant.  I say
> it because I am self consistent

I disagree; refer to your interval arithmetic as an example.
It's not magic, except when you believe there's no way for
somebody else to provide the necessary information.

> - I oppose unnecessary complexity
> in computing environments.

Which depends entirely on what you consider necessary and
unnecessary.

>>> At least all of the story that the I/O library knows without
>>> arbitrarily making up information out of the air!

>> There's more to the matter than just the I/O library.

> As you've reminded me in three messages now, none of
> those are on topic in this thread.  What is Fortran I/O to
> do with floating point output *NOW*?

That's been addressed by members of the standards committee.
The answer apparently isn't clear because of contradictions
involving the sign bit, which wants a minus sign to be attached,
and the SP edit descriptor, which wants a plus sign to be
attached.

The issue to which I responded was your reference to an exact
zero.

>>> And it has a 100% chance of being wrong if it claims that the
>>> answer is *exact* zero.

>> But you claimed that there is no such thing.  [...]

> So that makes it even more wrong for the I/O library to claim it!

So you consider yourself the final arbiter in what an I/O library
should do.

>> [...]                                Although I disagree,
>> that doesn't mean I believe the thermometer example represents a
>> case of an exact zero.

> You said it was before.

No I didn't.

> You *defined* exact zero as the difference
> of two values with identical internal represenations.

But I used an example that was quite different from your
thermometer example.

> You made no
> allowances for the provenance of the numbers involved.

I've talked about the uncertainties of the numbers.  I've talked
about propagation of error.

> Your own
> words require that you believe that the thermometer example
> represents a case of exact zero.

Not at all.  Propagate the quantization error of 0.1 degrees.

>>> That's not an improvement.

>> Irrelevant, given that I never said it would be an improvement.

> Good, now we're getting somewhere.

Not yet, because you've misinterpreted your thermometer example
as being equivalent to my concept of an exact zero.

> Can we now stop talking
> about changing the admirable rule Fortran already has for writing
> zeros?

We haven't been talking about that.  We've been talking about an
exact zero.  I'll leave it to the standards committee members to
clarify the standard.

>>> The existing implementation is writing all zero digits for the
>>> value already.  To anyone with an understanding of float, that
>>> means the value (the result of a subtract), by itself, has no
>>> significance at all, much less does the sign mean anything.

>> So a single sign bit isn't sufficient.

> For a quantity that means nothing, it's overspecified.

What about for a quantity that means something?

> That means it's *more* than sufficient.  There's certainly no need
> for even more.

When the quantity means nothing.  What about when it means something?

>> Unfortunately, the compiler doesn't spit out the intention of
>> notational conventions along with the numerical results.  Do
>> you have any Fortran compiler documentation that explains how
>> signs are handled?

> The standard is pretty precise.  Taken with the specification
> of whatever float representatin you use, it's conclusive.

So you're saying that everyone who buys a compiler also needs to
buy a copy of the standard implemented by that compiler in order
to learn how to properly use the compiler?

>>> Then by gosh the programmer can write a string of plusses and
>>> minuses or draw a picture of a clown if (s)he wants.

>> Imagine that, extra bits to work with.  [...]

> Extra bits on output you mean.

No.  I mean extra bits.  In the past, compiler vendors would
have different choices for the number of bits to assign to
the exponent and to the rest of the number.  They chould just
as easily reserve one of those bits for another purpose.

> No extra bits on input (to the I/O library) though.

Why not?

> This extra noise warns the user of a bogus
> problem in a bogus way.  I can't prevent a bad programmer from
> doing it.  I can't prevent all sorts of counterproductive behavior.

You're presupposing that having a bit reserved to do something
else represents noise.  That's not necessarily the case.

>> [...]                       Do the propagation of
>> error computation, show what the uncertainty in the result is, [...]

> Not unless the I/O library is given that information.  NO?  You
> didn't pass that data?  You didn't say *specifically* (as I keep
> asking) what you expect the I/O library to do?  No, you didn't.

What are you harping about now?  I've already said what I expect
given the current situation.  And I've already talked about other
possibilities for the future.

> And interestingly, if you *do* a formal error propagation
> analysis, the existing rules for handling signs (even of zeros)
> are sufficient to clearly report the results.

Really?  Then which sign is the correct sign for your thermometer
example?  Sorry, the answer is neither.  There's no way for the
processor to know which sign to pick.

>> I disagree.  A single bit has only two states, but there are more
>> than two possible outcomes.  Doing a propagation of error
>> computation carries far more information.

> Then *DO* *IT*.

That's exactly what I do in my own work.  But that's not the issue
here.  The issue here is whether there is such a thing as an exact
zero.  If you prefer, consider Shepard's absolute zero.  There has
to be a dividing line between where you use minus and where you use
plus.  You may feel as though a result can never be on that dividing
line, but the concept of the dividing line must be present to
separate the plusses from the minuses.  Is that a better concept of
an exact zero?

> You mentioned none of this before!

Kevin Rhoads should disagree, considering the amount of time we
spent discussing it.

> Your
> previous claims were entirely based on just the normal float
> results.

My previous claim for the thermometer example is based on the
fact that the processor can't know which sign to use.

> This is like the bad mystery writer that tells a long
> story with lots of clues concerning central characters and then
> reveals the crime was committed by a stranger that was just caught
> in the next state.  What a gyp.  Ringing in a whole different
> issue never mentioned before. and so late in the game.

You're erroneously presupposing that it's never been mentioned
before.

>>> What a responsible programmer will do is label the output.
>>> Something like: "first differences of temperature readings".

>> You think that's more responsible than a full propagation of
>> error computation?  Of course, you have to do the computation
>> properly.  Too often quantization noise is ignored.

> In this simple case, I think the savvy reader knows what the
> error was without such expensive analysis.  The source of
> error is the reliability of the thermometer and the fact that
> it discretized the data.  The only operation is a subtract.

Actually, a subtract without a time normalization isn't terribly
useful.  If you sample the temperature every nanosecond, you
could get lots of identical results, given the quantization.
Sample every hour and you just might get around that problem.
But then you need a divide in there as well to compute the
rate of change.

I've actually taught students about the problems of quantization
noise.  The specific exercise involved the timing of the period
of a pendulum using a stopwatch.  The way around the problem is
to time multiple periods and divide by that multiple.  Also
reduces error contributed by human reaction time.  But it increases
the error caused by atmospheric friction.

> No, a *really* complex, slow method is like killing a fly
> with an atomic bomb.

And that is relevant how?

Wade Ward writes:

>> glen herrmannsfeldt wrote:

>>> In this case, I think tholen's license should be revoked.

>> Fortunately, what you think is irrelevant, glen.  The facts are
>> relevant, and you haven't presented any fact that I don't know
>> how to use floating point arithmetic.

> I find plenty of relevance in what Glen has to say.

Glen hasn't said anything factual about my use of floating point
arithmetic.  How can there be any relevance?

> Of course, I don't care one way or the other,

You obviously cared enough to respond.

> because for me, zero is the element that fulfills 
> properties necessary to make a ring, but that's math, not fortran, and not 
> IEEE.

And therefore irrelevant to the present discussion.

> That you're on the wrong side of IEEE is one problem.

I haven't taken sides with regard to the IEEE.  What I took sides on
is Giles' comment about exact zero.

> That you're on 
> the wrong side of Glen usually just puts you on the wrong side.

Not in this case, unless you're prepared to present some facts in the
matter that you believe demonstrate otherwise.

Gary Scott wrote:
....
> For example, what if my specification for how the display is to appear
> (defined by some nebulous system designer somewhere) requires
> specifically that the display value be displayed as 0.0 through 9.9?

Why not do a sanity chect before the output (which would be a
good idea anyway) and then remove any hypothetical sign from
the zero after you've passed the sanity check.

This all assumes the existence of a rather parochial system designer
in the first place....

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
> James Giles writes:
....
>> Interval arithmetic carries *a* *lot* more information.
>
> There's your "magic".
>
>> Yes, if you provide the I/O library with a new data type
>> (intervals) the I/O thenhas something else to work with.
>> It's not magic, it's well defined, hardnosed, pragmatic
>> I/O.
>
> So, I answer your question about the magic by referring to something
> you brought up, and now suddenly it's not magic anymore.  Why am I
> not surprised?

Your recommendations about how to supress (or not supress)
signs *never* mentioned any auxillary information being
provided to the I/O library.  (Newsgroup archived, people
can check).  Your suggestions really did require magic.

By the way, reporting error propagation analyses need no changes
to the IEEE nor to I/O.  They're both admirably up to the task.


> [...]                I specified my concept
> of an exact zero.

Yeah, the difference of two identically represented values
(with no qualifications about their origins).  That's the
opposite of everyone else's definition of exact anything.
Isn't it revealing that a difference resulting in zero was the
only condition to raise the inexact conditon on some
hardware?

>> No one will buy a backward step as progress.  Mysticism is a
>> dark age phenomenon.
>
> Irrelevant, given that I haven't proposed any backward step.

In the opinion of one person.

>> I say it because there aren't more than two *IMPORTANT*
>> outcomes.
>
> Just because a third one isn't important to you doesn't mean that it
> can't be important to someone else.

And the existing mechanism requires *no* additional features
or changes in the rules of I/O for you to voluntarily keep track
of as many irrelevancies as you wish.  I just don't want yet
another raft of features and options that I have to work hard
to turn off that provide no sensible value.

....

>> You *defined* exact zero as the difference
>> of two values with identical internal represenations.
>
> But I used an example that was quite different from your
> thermometer example.

You gave two numbers of unknown provenance.  For all I know
you read them off a list of recorded temperatures.  You gave
*no* qualifications regarding their provenance in your definiton
of "exact".  You didn't even suggest that any such qualifications
were forthcoming or that any might be relevant.  In fact, your
statement was quite devoid of any notion of exceptions to your
definition at all.


> We haven't been talking about that.  We've been talking about an
> exact zero.  I'll leave it to the standards committee members to
> clarify the standard.

Good, then there's nothing to discuss at all.  There aren't
exact zeros.

-- 
>J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> Still completely ignoring the topic above (the subject line)

If that's a problem for you, why didn't you change it when you
brought up the matter of an exact zero?

> ....

>>> You've maintained that zeros are exact even
>>> when dealing with simulated continuous reals

>> Where did I allegedly say that?  I've not claimed that all such
>> zeros are exact.  A subset of such zeros could be exact, according
>> to the definition I provided.

> Why do people insist on misrepresenting their own prior statements
> in usenet newsgroups? 

Irrelevant to the present discussion.  I see that you didn't answer
my question about where I allegedly said that zeros are exact even
when dealing with simulated continuous reals.

> The group is archived.  You said nothing
> about subsets in your definition.

I also said nothing about all such zeros being exact.

> Your definition was stated without qualificaton.

The IAU's planet definition committee stated their proposed definition
of "planet".  But some people didn't agree with it, so it went back to
committee for further discussion.  If you don't like my definition of
an exact zero for some reason, I'm open to discussing it further.
Indeed, one person did bring up the matter of most representations of
real numbers being approximations, and I responded by saying that the
definition could be restricted to that subset of real numbers that
could be exactly represented, if he liked that better.  Clearly I'm
open to modifications to achieve something that could be more widely
accepted.

> Look for yourself

I already know what I wrote.

> (most others don't need to, they know I'm right).

About what?  Certainly not about your claim that I maintained that
zeros are exact even when dealing with simulated continuous reals.

>>> (the very purpose
>>> of the temperature example was to make *sure* the values involved
>>> were definitely known in advance to be inexact).

>> But my definition of an exact zero was made before you offered
>> your temperature example:  the difference of two identical
>> internal representations.  [...]

> And you repeated it several times, even in direct reference to that
> very example.

What do you consider a direct reference?  What I said in direct
reference to your example is that there is no way for the processor
to know which sign to use.

> Look for yourself.

I already know what I wrote.

> Anyone that's forgotten it can check too.  The group is archived.

Good.

> ....
> Yada yada...
>
> Why not answer the question put to you?

Which question are you talking about?

> What do you recommend
> Fortran do *now*.

The discussion was about your reference to an exact zero.  As I
already said, I'll leave it up to the standards committee to
issue an interpretation of the standard regarding the sign bit
and SP edit descriptor contradiction.  Why are you trying to
divert attention away from the issue I've been discussing with
you?

> Not after some hypothetical change to the number
> system - now.

No hypothetical change to the number system needs to be made to
define an exact zero.

> Not after you provide your never-before-mentioned
> error propagation analysis - now.

You're erroneously presupposing that I never mentioned error
propagation before now.

> Answer the question.

Which question are you talking about?

>>>> No, I *like* progress.  I like it alot. That's why I embrace signed
>>>> zeros.

>> So why not encourage the next step rather than saying "live with it"?

> Your advice about the next step is counterproductive, expensive,
> and without merit.

Do you have any substantiation for that claim?

> Suggest an advance and you'll get interest.

How about suggesting magic?  Like interval arithmetic?

>> But I haven't proposed to do any unnecessary work, Giles.

> So far you haven't proposed that *you* do any work at all.

So why the accusation?

> You place it on others to provide you with unnecessarily complex
> multiply signed floats.

I've done no such thing.

> You insist on some (yet to be specified)
> way of deciding within the I/O library what arcane new
> ways to display zeros that avoid signs (or not?  you haven't
> specified, you just keep refusing).

I've done no such thing.

> But  *you're* not acting
> to explicitly work on those "solutions".

I'm discussing the concept of an exact zero.  If we can agree that
there is one, then we can move on to the next step of how to deal
with it.  First things first.

> Of course, there is no problem, so no "solutions" need be
> found anyway.

You don't think a minus sign (or a plus sign) on an exact zero
is a problem?

> Probably just as well you're so intentially vague.

Exactly what are you trying to say?  I'm unfamiliar with the
word "intentially".

>>> [...]              but the whole
>> concept of a sign on the zero requires the concept of an
>> absolute zero, [...]

> Now that's funny!!!

What's allegedly funny about it, Giles?  And would be more careful
with your editing?  By having three levels of indentation on the
line with "but the whole", you're indicating that you authored
that text.

>> So, you believe that computational mathematics needs nothing more
>> than just two kinds of zero?

> It often doesn't even need two.

What about the other cases?

> It certainly needs no more.

Why do you say that?

> At least not based on anything you've said. Everything
> you've mentioned as problems are actually better without
> your suggested changes (and even the ones you're refused to
> suggest).

Yet another claim without substantiation from you.  You didn't
even distinguish between the alleged suggestions and the alleged
refusal to suggest.

tholen@antispam.ham wrote:
> James Giles writes:
....
>> Why do people insist on misrepresenting their own prior statements
>> in usenet newsgroups?
>
> Irrelevant to the present discussion.  [...]

So you don't deny you're now misrepresenting your own
statements?  Good.

> [...]    I see that you didn't answer
> my question about where I allegedly said that zeros are exact even
> when dealing with simulated continuous reals.

Well if you now want to claim you didn't, fine.  I preceeded you
in stating that arithmetic on a small, discrete subset of the rationals
was exact.  So, now you're claiming to have made the same same
statement all along.  Good, that means that you probably also now
agree that when your calculation is not confined to that subset,
but is instead dealing with simulating comntinuous reals, there
are no exact zeros.  Fine.  That's what I'ved said all along.
I never made any claim exceeding those two.  Read the
archive.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> ...
> 
>>For example, what if my specification for how the display is to appear
>>(defined by some nebulous system designer somewhere) requires
>>specifically that the display value be displayed as 0.0 through 9.9?
> 
> 
> Why not do a sanity chect before the output (which would be a
> good idea anyway) and then remove any hypothetical sign from
> the zero after you've passed the sanity check.
> 
> This all assumes the existence of a rather parochial system designer
> in the first place....
> 
Don't know about parochial, but it is a common aircraft display design 
scenario and where the customer gets what the customer (pilot) wants, 
not what the designer things is best necessarily.  Yes, of course I 
could do an internal write and manipulate it, however, I'd prefer what 
most people would expect which is to not differentiate unless requested 
to do so.  Most people (outside of mathameticians and floating point 
minutia afficiandos) have never heard of the concept of negative zero. 
The common definition of negative is something less than zero and 
positive is something greater than zero with zero having neither 
negative or positive qualities.  It seems to me like we're trying to 
represent something that is basically an error condition as a normally 
expected result because of internal representation characteristics.  But 
I'm trying not to follow this too closely.  You'll all resolve it one 
way or t'other.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

<tholen@antispam.ham> wrote in message 
news:46a2881c$0$20548$4c368faf@roadrunner.com...
> glen herrmannsfeldt writes:

>> In this case, I think tholen's license should be revoked.
>
> Fortunately, what you think is irrelevant, glen.  The facts are
> relevant, and you haven't presented any fact that I don't know
> how to use floating point arithmetic.
I find plenty of relevance in what Glen has to say.  Of course, I don't care 
one way or the other, because for me, zero is the element that fulfills 
properties necessary to make a ring, but that's math, not fortran, and not 
IEEE.  That you're on the wrong side of IEEE is one problem.  That you're on 
the wrong side of Glen usually just puts you on the wrong side.
-- 
Wade Ward 

Gary Scott wrote:
....
> [...]  Yes, of course I
> could do an internal write and manipulate it,[...]

I don't know why you keep mentioning internal writes.  I've
already twice described to you a simpler method what avoids
that step.  Check (for sanity) that the numbers you are producing
really have the properties you expect.  then clear the sign bit
of any zero in the list.

> [...]                  however, I'd prefer what
> most people would expect which is to not differentiate unless
> requested to do so.  Most people (outside of mathameticians and
> floating point minutia afficiandos) have never heard of the concept
> of negative zero.  [...]

Interesting that your description is opposite my own experience
in actually asking people what they want.  I mention the possibility
of negative zero, they want to hear more, and end up volunteering
that the sign should not be hidden by the I/O.  If I suggest that
it *could* be so hidden, they request that it not be.  You might
say I'm interested (or was, when I was writing an I/O support
library for Fortran).  I wanted to know.

Sure, they often didn't previously know about signed zeros.  But
that all the more indicated that they've never been confused by
them.  They all have the reaction: "come to think of it, I wondered
about that."  But they weren't troubled.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ....

>>> Interval arithmetic carries *a* *lot* more information.

>> There's your "magic".

>>> Yes, if you provide the I/O library with a new data type
>>> (intervals) the I/O thenhas something else to work with.
>>> It's not magic, it's well defined, hardnosed, pragmatic
>>> I/O.

>> So, I answer your question about the magic by referring to something
>> you brought up, and now suddenly it's not magic anymore.  Why am I
>> not surprised?

> Your recommendations about how to supress (or not supress)
> signs *never* mentioned any auxillary information being
> provided to the I/O library.

The I/O library is irrelevant to defining the concept of an
exact zero.  If you accept that an exact zero can exist, then
we can discuss how to implement detection.  First things first.

> (Newsgroup archived, people can check).

Indeed they can.

> Your suggestions really did require magic.

Suddenly interval arithmetic is magic again.  But it's not
magic when it suits you.

> By the way, reporting error propagation analyses need no changes
> to the IEEE nor to I/O.  They're both admirably up to the task.

So what's magic about it?

>> [...]                I specified my concept
>> of an exact zero.

> Yeah, the difference of two identically represented values
> (with no qualifications about their origins).

My example involved initialization.

> That's the
> opposite of everyone else's definition of exact anything.

How is it the opposite?

> Isn't it revealing that a difference resulting in zero was the
> only condition to raise the inexact conditon on some
> hardware?

But not on other hardware?

>>> No one will buy a backward step as progress.  Mysticism is a
>>> dark age phenomenon.

>> Irrelevant, given that I haven't proposed any backward step.

> In the opinion of one person.

You're only one person, Giles.

>>> I say it because there aren't more than two *IMPORTANT*
>>> outcomes.

>> Just because a third one isn't important to you doesn't mean that it
>> can't be important to someone else.

> And the existing mechanism requires *no* additional features
> or changes in the rules of I/O for you to voluntarily keep track
> of as many irrelevancies as you wish.

I'm not tracking irrelevancies, which, ironically, makes your
statement irrelevant.

> I just don't want yet
> another raft of features and options that I have to work hard
> to turn off that provide no sensible value.

I haven't been talking about features and options, Giles.  I've
been talking about the existence of an exact zero.

> ....

>>> You *defined* exact zero as the difference
>>> of two values with identical internal represenations.

>> But I used an example that was quite different from your
>> thermometer example.

> You gave two numbers of unknown provenance.

I gave two variable initializations.

> For all I know
> you read them off a list of recorded temperatures.

That's your example, Giles, not mine.

> You gave
> *no* qualifications regarding their provenance in your definiton
> of "exact".

You're really having trouble comprehending what I've written,
haven't you?  Or is it that you've found what I've written too
inconvenient, so you replace it with four dots and ignore it?

I gave you the example of the IAU's definition of "planet", and
how it was modified to deal with objections.  I even gave you
example of someone else's objection to my proposed definition of
an exact zero, and how I proposed to deal with it.  Clearly I'm
open to modifying the definition to satisfy objections, but all
you can do is keep complaining about the lack of qualifications.

> You didn't even suggest that any such qualifications
> were forthcoming or that any might be relevant. In fact, your
> statement was quite devoid of any notion of exceptions to your
> definition at all.

My statement was also devoid of any notion of inflexibility to
modification in response to objections, Giles.

>> We haven't been talking about that.  We've been talking about an
>> exact zero.  I'll leave it to the standards committee members to
>> clarify the standard.

> Good, then there's nothing to discuss at all.

On the contrary, there's your statement about exact zeros.

> There aren't exact zeros.

"In the opinion of one person."

James Giles writes:

> ....

>>> Why do people insist on misrepresenting their own prior statements
>>> in usenet newsgroups?

>> Irrelevant to the present discussion.  [...]

> So you don't deny you're now misrepresenting your own
> statements?

I said it's irrelevant because I haven't been misrepresenting my own
prior statements, Giles.

> Good.

Classic erroneous presupposition.

>> [...]    I see that you didn't answer
>> my question about where I allegedly said that zeros are exact even
>> when dealing with simulated continuous reals.

> Well if you now want to claim you didn't, fine.

So, you don't deny you're now misrepresenting my prior statements?

> I preceeded you
> in stating that arithmetic on a small, discrete subset of the rationals
> was exact.

Does that discrete subset include zero?

> So, now you're claiming to have made the same same
> statement all along.

Where have I made such a claim?

> Good, that means that you probably also now
> agree that when your calculation is not confined to that subset,
> but is instead dealing with simulating comntinuous reals, there
> are no exact zeros.  Fine.  That's what I'ved said all along.
> I never made any claim exceeding those two.  Read the
> archive.

Unnecessary.  But you should practice what you preach, Giles.

tholen@antispam.ham wrote:
....
> The I/O library is irrelevant to defining the concept of an
> exact zero.  If you accept that an exact zero can exist, then
> we can discuss how to implement detection.  First things first.

In simulating continuous reals, there are no exact zeros. No
detection is possible for nonexistent beasts.  In confining
yourself to the appropriate discrete subset of rationals, all
values are exact and detection isn't needed.  No changes to
the IEEE standard or my recommendation for I/O are
necessary or desirable.

>> Your suggestions really did require magic.
>
> Suddenly interval arithmetic is magic again.  But it's not
> magic when it suits you.

You never suggested interval arithmetic (or any other error
tracking mechanism) in your statements about I/O.  They
were obviously just magical.  For you to now jump on the
bandwagon and claim that your remarks implied error
analysis all along is just false.  But let the readers decide.

>> By the way, reporting error propagation analyses need no changes
>> to the IEEE nor to I/O.  They're both admirably up to the task.
>
> So what's magic about it?

Since they needn't do what you've recommended in the past,
nothing.  The don't need to have multi-bit signs.  They don't
need extended character sets to display their values.  They
don't need to make decisions based on (apparently) no
information.  All those things were *your* "contributions".

>>> [...]                I specified my concept
>>> of an exact zero.
>
>> Yeah, the difference of two identically represented values
>> (with no qualifications about their origins).
>
> My example involved initialization.

Yeah, to values with no provenance and your discussion
didn't mention the need for any.  "Inexact" is the only reasonable
conclusion.

> I haven't been talking about features and options, Giles.  I've
> been talking about the existence of an exact zero.

Well, I'll let readers decide whether your frequent discussion
about such inventions as multi-bit signs and such constitute
"features and options".  (I think you're misrepresenting your
own statements again).

And you finally agreed last time that exact zeros don't exist when
simulating continuous reals.  That's all I ever said.  Or are you
going to renege on that too?  :-(

tholen@antispam.ham also wrote:

> So, you don't deny you're now misrepresenting my prior statements?

I'm quite willing to let readers decide who is misrepresent what.
I'm confident of their conclusions.  My conscience is completely
clear.

>> I preceeded you
>> in stating that arithmetic on a small, discrete subset of the
>> rationals was exact.
>
> Does that discrete subset include zero?

I already said so.  It's not the continuous reals though,
so an exact zero (or any other number)  in this context
is *irrelevant* to my statement that in simulating continuous
reals there are no exact zeros.  There aren't.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ....

>> The I/O library is irrelevant to defining the concept of an
>> exact zero.  If you accept that an exact zero can exist, then
>> we can discuss how to implement detection.  First things first.

> In simulating continuous reals, there are no exact zeros.

You keep repeating the same claim, but you don't offer any proof
of that claim.  Do you deny that a subset of continuous reals
can be represented exactly with a finite number of bits?

> No detection is possible for nonexistent beasts.

You're presupposing that the beast is nonexistent.

> In confining
> yourself to the appropriate discrete subset of rationals, all
> values are exact and detection isn't needed.  No changes to
> the IEEE standard or my recommendation for I/O are
> necessary or desirable.

Once again you've evaded the question as to whether zero is a
member of the subset.

>>> Your suggestions really did require magic.

>> Suddenly interval arithmetic is magic again.  But it's not
>> magic when it suits you.

> You never suggested interval arithmetic (or any other error
> tracking mechanism) in your statements about I/O.

I suggested interval arithmetic in other statements, Giles.
Interesting that you would ignore those.

> They were obviously just magical.

Another erroneous presupposition on your part, Giles.

> For you to now jump on the
> bandwagon and claim that your remarks implied error
> analysis all along is just false.

I've done no such thing, Giles.

> But let the readers decide.

And they can decide that you once again tried to put words in my
mouth.

>>> By the way, reporting error propagation analyses need no changes
>>> to the IEEE nor to I/O.  They're both admirably up to the task.

>> So what's magic about it?

> Since they needn't do what you've recommended in the past,
> nothing.

Didn't stop you from calling it magic, Giles.

> The don't need to have multi-bit signs.

More than one way to skin a cat, as the saying goes.

> They don't need extended character sets to display their values.

Irrelevant, given that I never said otherwise.

> They don't need to make decisions based on (apparently) no
> information.  All those things were *your* "contributions".

Untrue.

>>>> [...]                I specified my concept
>>>> of an exact zero.

>>> Yeah, the difference of two identically represented values
>>> (with no qualifications about their origins).

>> My example involved initialization.

> Yeah, to values with no provenance and your discussion
> didn't mention the need for any.

My discussion included a programming example, Giles.

> "Inexact" is the only reasonable conclusion.

In the opinion of one person.

>> I haven't been talking about features and options, Giles.  I've
>> been talking about the existence of an exact zero.

> Well, I'll let readers decide whether your frequent discussion
> about such inventions as multi-bit signs and such constitute
> "features and options".  (I think you're misrepresenting your
> own statements again).

What you think is irrelevant, Giles.  Rather, you're the one
attempting to misrepresent my statements.

> And you finally agreed last time that exact zeros don't exist when
> simulating continuous reals. 

Also untrue.  Yet another misrepresentation of what I said on your
part, Giles.

> That's all I ever said. 

I'm still waiting for you to say whether zero is a member of the
subset of continuous real numbers that have exact internal
representations, Giles.

> Or are you going to renege on that too?  :-(

I'm not taking back anything, Giles.

>> So, you don't deny you're now misrepresenting my prior statements?

> I'm quite willing to let readers decide who is misrepresent what.

Good.

> I'm confident of their conclusions.

So am I, at least for those with decent reading comprehension skills.

> My conscience is completely clear.

So is mine.

>>> I preceeded you
>>> in stating that arithmetic on a small, discrete subset of the
>>> rationals was exact.

>> Does that discrete subset include zero?

> I already said so.

So, there is such a thing as an exact zero, contrary to your claim.

> It's not the continuous reals though,

It's a subset of them.

> so an exact zero (or any other number)  in this context
> is *irrelevant* to my statement that in simulating continuous
> reals there are no exact zeros.

I disagree.

> There aren't.

   "Does that discrete subset include zero?"

   "I already said so."

James Giles wrote:
> Gary Scott wrote:
> ...

>> [...]                  however, I'd prefer what
>> most people would expect which is to not differentiate unless
>> requested to do so.  Most people (outside of mathameticians and
>> floating point minutia afficiandos) have never heard of the concept
>> of negative zero.  [...]
> 
> Interesting that your description is opposite my own experience
> in actually asking people what they want.  I mention the possibility
> of negative zero, they want to hear more, and end up volunteering
> that the sign should not be hidden by the I/O.  If I suggest that
> it *could* be so hidden, they request that it not be.  ...
....

I'd think that response would depend at least fairly strongly on the 
sample population of respondents -- I can think of various areas I've 
worked in where the answer would probably reflect both your experience 
and Gary's desires...

--

dpb wrote:
> James Giles wrote:
>> Gary Scott wrote:
>> ...
>
>>> [...]                  however, I'd prefer what
>>> most people would expect which is to not differentiate unless
>>> requested to do so.  Most people (outside of mathameticians and
>>> floating point minutia afficiandos) have never heard of the concept
>>> of negative zero.  [...]
>>
>> Interesting that your description is opposite my own experience
>> in actually asking people what they want.  I mention the possibility
>> of negative zero, they want to hear more, and end up volunteering
>> that the sign should not be hidden by the I/O.  If I suggest that
>> it *could* be so hidden, they request that it not be.  ...
> ...
>
> I'd think that response would depend at least fairly strongly on the
> sample population of respondents -- I can think of various areas I've
> worked in where the answer would probably reflect both your experience
> and Gary's desires...

Well, I don't think either of us claims to really have *actually* asked
a majority of people, nor even a "scientifically selected representative
sample".  And the response on surveys is known to depend on how
the question is asked (I explain the issue first, then ask - because I
don't see the value of completely uninformed responses).

As Glen would say: for comparison purposes, most programming
languages require negative zeros to be written with a minus sign.
I can't think of any (that mention it at all) that don't have such a
requirement.  (If they don't mention it, most likely they just rely
on an I/O library written for some other language and just accept
what it does.  These days that means a C library most of the time.
C requires that negative zero be written with a minus sign.)

And the people that *really* care, the scientific/numerical computing
crowd, they're pretty uniform in their position: don't remove the sign.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

tholen@antispam.ham wrote:
....
>> In simulating continuous reals, there are no exact zeros.
>
> You keep repeating the same claim, but you don't offer any proof
> of that claim.  Do you deny that a subset of continuous reals
> can be represented exactly with a finite number of bits?

Do you deny that a discrete subset of the continuous reals is
discrete?  A property of a subset isn't necessarily a property
of the whole set.  Reals aren't discrete even though quite a
few differntly defined subsets of the reals are discrete.

That's relevant because exactitude in computing is only
possible on discrete sets.  When simulating continuous sets
yuo have no exactitude.  In simulating continuous reals there
are no exact numbers, zeros or otherwise.

Well, you're now getting abusive as well.  I have no interest
in further proving you wrong.  No doubt you'll claim I've
done no such thing.  In fact, nothing you've said is even
slightly interesting, much less convincing that anything I've
said is wrong.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> dpb wrote:
> 
>>James Giles wrote:
>>
>>>Gary Scott wrote:
>>>...
>>
>>>>[...]                  however, I'd prefer what
>>>>most people would expect which is to not differentiate unless
>>>>requested to do so.  Most people (outside of mathameticians and
>>>>floating point minutia afficiandos) have never heard of the concept
>>>>of negative zero.  [...]
>>>
>>>Interesting that your description is opposite my own experience
>>>in actually asking people what they want.  I mention the possibility
>>>of negative zero, they want to hear more, and end up volunteering
>>>that the sign should not be hidden by the I/O.  If I suggest that
>>>it *could* be so hidden, they request that it not be.  ...
>>
>>...
>>
>>I'd think that response would depend at least fairly strongly on the
>>sample population of respondents -- I can think of various areas I've
>>worked in where the answer would probably reflect both your experience
>>and Gary's desires...
> 
> 
> Well, I don't think either of us claims to really have *actually* asked
> a majority of people, nor even a "scientifically selected representative
> sample".  And the response on surveys is known to depend on how
> the question is asked (I explain the issue first, then ask - because I
> don't see the value of completely uninformed responses).
> 
> As Glen would say: for comparison purposes, most programming
> languages require negative zeros to be written with a minus sign.
> I can't think of any (that mention it at all) that don't have such a
> requirement.  (If they don't mention it, most likely they just rely
> on an I/O library written for some other language and just accept
> what it does.  These days that means a C library most of the time.
> C requires that negative zero be written with a minus sign.)
> 
> And the people that *really* care, the scientific/numerical computing
> crowd, they're pretty uniform in their position: don't remove the sign.
> 
I think the only significant point is that I'm perfectly happy with it 
being included.  Just don't be dictatorial about it and disallow me the 
convenience of an option to omit it.  (abs()???...yuk)

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
....
> I think the only significant point is that I'm perfectly happy with it
> being included.  Just don't be dictatorial about it and disallow me
> the convenience of an option to omit it.  (abs()???...yuk)


As useless features go, it's not *that* big I suppose.

But it is just another thing to recommend people not do.  I don't
think the benefit (if there is one) is worth the cost of debating it,
standardizing it, implementing it, and teaching it.  Still, if you
can push it through I guess ther are worse things already in the
language.  Just don't make it the default.  Don't make it easy
to accidentally trigger.  Don't make it easy to forget to turn
off after the one rare case in the whole code where it's "needed".
Etc.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> ...
> 
>>I think the only significant point is that I'm perfectly happy with it
>>being included.  Just don't be dictatorial about it and disallow me
>>the convenience of an option to omit it.  (abs()???...yuk)
> 
> 
> 
> As useless features go, it's not *that* big I suppose.
> 
> But it is just another thing to recommend people not do.  I don't
> think the benefit (if there is one) is worth the cost of debating it,
> standardizing it, implementing it, and teaching it.  Still, if you
> can push it through I guess ther are worse things already in the
> language.  Just don't make it the default.  Don't make it easy
> to accidentally trigger.  Don't make it easy to forget to turn
> off after the one rare case in the whole code where it's "needed".
> Etc.
> 
The default should probably be whatever the common behavior currently 
is.  That way it breaks less existing code.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

James Giles wrote:
> dpb wrote:
>> James Giles wrote:
>>> Gary Scott wrote:
>>> ...
>>>> [...]                  however, I'd prefer what
>>>> most people would expect which is to not differentiate unless
>>>> requested to do so.  Most people (outside of mathameticians and
>>>> floating point minutia afficiandos) have never heard of the concept
>>>> of negative zero.  [...]
>>> Interesting that your description is opposite my own experience
>>> in actually asking people what they want.  I mention the possibility
>>> of negative zero, they want to hear more, and end up volunteering
>>> that the sign should not be hidden by the I/O.  If I suggest that
>>> it *could* be so hidden, they request that it not be.  ...
>> ...
>>
>> I'd think that response would depend at least fairly strongly on the
>> sample population of respondents -- I can think of various areas I've
>> worked in where the answer would probably reflect both your experience
>> and Gary's desires...
> 
> Well, I don't think either of us claims to really have *actually* asked
> a majority of people, nor even a "scientifically selected representative
> sample".  And the response on surveys is known to depend on how
> the question is asked (I explain the issue first, then ask - because I
> don't see the value of completely uninformed responses).
....

I wasn't arguing the validity or anything, simply commenting it would 
depend on the audience...

--

Gary Scott wrote:
....
> The default should probably be whatever the common behavior currently
> is.  That way it breaks less existing code.


The always outputting minus if the data is negative is the default.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles wrote:

> Gary Scott wrote:
> ...
> 
>>The default should probably be whatever the common behavior currently
>>is.  That way it breaks less existing code.
> 
> 
> 
> The always outputting minus if the data is negative is the default.
> 
ok, but all of my existing compilers print -0.0 as just 0.0.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
> James Giles wrote:
....
>> The always outputting minus if the data is negative is the default.
>>
> ok, but all of my existing compilers print -0.0 as just 0.0.

The standard requires negative numbers to be written with a
minus sign.  If your compilers are in violation of the standard
then you ought to have them fixed.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ....

>>> In simulating continuous reals, there are no exact zeros.

>> You keep repeating the same claim, but you don't offer any proof
>> of that claim.  Do you deny that a subset of continuous reals
>> can be represented exactly with a finite number of bits?

> Do you deny that a discrete subset of the continuous reals is
> discrete?

I see that you didn't answer my question.

> A property of a subset isn't necessarily a property
> of the whole set.

A member of a subset is a member of the whole set.  Is zero a
member of that subset?

> Reals aren't discrete even though quite a
> few differntly defined subsets of the reals are discrete.

Is zero a member of a discrete subset?

> That's relevant because exactitude in computing is only
> possible on discrete sets.

We're not talking about exactitude in general.  We're talking
about the existence of an exact zero.

> When simulating continuous sets
> yuo have no exactitude.

So whenever the topic becomes whether pi is exact or not, you
can raise that point.  But the issue is zero, not pi.

> In simulating continuous reals there
> are no exact numbers, zeros or otherwise.

I disagree.  Consider the subset of reals that can be exactly
represented.  I zero a member of that subset?

> Well, you're now getting abusive as well.

Classic unsubstantiated and erroneous claim.

> I have no interest in further proving you wrong.

Classic erroneous presupposition that you've proved me wrong.

> No doubt you'll claim I've done no such thing.

With good reason.

> In fact, nothing you've said is even slightly interesting,

On the contrary, you've been interested enough in what I've said
to keep responding for several days, several times per day.

> much less convincing that anything I've said is wrong.

If you want to go through life thinking that there's no way for
a processor to represent an exact zero, that's your choice, Giles.

Richard Maine writes:

> robert.corbett@sun.com wrote:

>> 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.

>> 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.

> I'm one of the members who indeed think that the word "may" means "may",
> but the above is an inaccurate representation of the position. The "but
> then again they may not" doesn't make sense to me as particularly
> related. As one of the people who I presume Bob is citing, I think I get
> some say in what I said. It wasn't that. Of course it might not (I'd say
> "might" instead of "may" for this usage, but that's a quibble). There
> never has been the least bit of question about the fact that there might
> be no prefix at all. In fact, with SS, there is required to be no prefix
> for positive values.
>
> The point was that the above says that "a zero internal may be prefixed
> by a plus sign, as controlled". However, that statement is not
> exclusionary. It doesn't say that a zero may not ever be preceeded by a
> minus sign.

It seems obvious to me that the use of "may" is due to the fact that
with SP, the sign would be present, and with SS, the sign would not be
present, thus use of "shall" is inconsistent with the inclusion of the
SS option in the sentence.

> In fact, since the above quote explicitly says that a negative value is
> prefixed with a minus sign, I find it difficult to interpret it any
> other way. A negative zero is negative.

In sign, but not in value, right?  10.6.1 above specifically refers to
values.  Otherwise, if X is a negative zero, then X < 0.0 would return
.TRUE., would it not?

> The line about how a zero may be prefixed with a plus is perhaps not
> perfectly clearly written, in that it doesn't make the parallel
> statement that a zero may be prefixed by a negative sign in some cases,
> but it at least does not contradict that possibility.

If "may" was used because the intent was "shall" for SP and "shall not"
for SS, then there is a contradiction.

James Giles writes:

> Gary Scott wrote:

>> James Giles wrote:

> ....

>>> The always outputting minus if the data is negative is the default.

>> ok, but all of my existing compilers print -0.0 as just 0.0.

> The standard requires negative numbers to be written with a
> minus sign.  If your compilers are in violation of the standard
> then you ought to have them fixed.

The standard also calls for a zero value being prefixed with a plus
sign when the SP edit descriptor is used.  Interesting dilemma.

tholen@antispam.ham wrote:
> James Giles writes:
...
>> The standard requires negative numbers to be written with a
>> minus sign.  If your compilers are in violation of the standard
>> then you ought to have them fixed.
>
> The standard also calls for a zero value being prefixed with a plus
> sign when the SP edit descriptor is used.  Interesting dilemma.

The industry wide convention when using the term "zero" (without
qualifier) is that it has two meanings.  When discussing a value
of a type that doesn't distinguish the sign of zero, it means the
only zero you've got.  When discussing a value of a data type
that *does* distinguish the sign of zero, it's a synonym for
"positive zero".  There's no dilemma.

There's no reason to expect that the committee didn't intend the
industry wide convention.  The observation that the paragraph is
contradictory if the industry wide convention is *not* applied
is all the more reason to assume that's what they intended.

They wanted to use one simple paragraph to give the rules for
all numeric types that Fortran might be implemented with.
Where they maybe should have said "non-negative values",
they said "positive or zero values" instead.  I think they
wanted to emphasize that even for data types that don't
distinguish the sign of zero the processor is permitted to
output a plus sign.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

James Giles writes:

> ...

>>> The standard requires negative numbers to be written with a
>>> minus sign.  If your compilers are in violation of the standard
>>> then you ought to have them fixed.

>> The standard also calls for a zero value being prefixed with a plus
>> sign when the SP edit descriptor is used.  Interesting dilemma.

> The industry wide convention when using the term "zero" (without
> qualifier) is that it has two meanings.  When discussing a value
> of a type that doesn't distinguish the sign of zero, it means the
> only zero you've got.  When discussing a value of a data type
> that *does* distinguish the sign of zero, it's a synonym for
> "positive zero".  There's no dilemma.

Isn't the value of a negative zero still zero?  When SP is used
with a positive or zero value, it's supposed to prefix the value
with a plus sign.  Hence the dilemma.

> There's no reason to expect that the committee didn't intend the
> industry wide convention.  The observation that the paragraph is
> contradictory if the industry wide convention is *not* applied
> is all the more reason to assume that's what they intended.

The way the standard is written is a reason to question the intent
of the committee.

> They wanted to use one simple paragraph to give the rules for
> all numeric types that Fortran might be implemented with.

I would expect them to want to use as little as possible, but as
much as necessary.

> Where they maybe should have said "non-negative values",
> they said "positive or zero values" instead.  I think they
> wanted to emphasize that even for data types that don't
> distinguish the sign of zero the processor is permitted to
> output a plus sign.

If there's no dilemma, then wouldn't the text be fine as it is?

On 2007-07-20, robert.corbett@sun.com <robert.corbett@sun.com> wrote:

> I would not
> be surprised if they don't deal with it in time for Fortran 1008.

I knew Fortran is an old programming language, but this is...
surprising.

Shouldn't it have Latin keywords (FINIS FACENDUM instead of END DO).

>>>Yes, but usually the computational error is smaller than other
>>>sources of error.  When they're not, higher precision is necessary. I 
>>>rarely use REAL*4 for the physical problems I deal with.  REAL*8
>>>is almost always adequate.
>>
>>But why would REAL*4, with its LSB relative error of about 10^-7, not
>>be adequate for most physical computation? I sure never measured
>>anything to even remotely that precision...
> 
> Relative error grows. 

Of course, that was the whole point of my answer to tholen! He was/is 
claiming, on the one hand, that computational error accumulation can be 
ignored, and then, on the other hand, suddenly said that he almost always uses 
REAL*8 instead of REAL*4.

But we already knew he was inconsistent.

And with regard to the other replies: Yes, I know about g-2, and some other 
examples for high-accuracy measurements. The astronomical one is actually 
quite interesting: Various compound values, in particular GM for various 
heavenly bodies, are known very well, as they can (and need be) measured to 
high precision for navigation. G, on the other hand, as one of the fundamental 
constants, is only known to 10^-3 or so, and likewise the related values for 
the masses of the bodies.

	Jan

Jan Vorbr�ggen wrote:

> But why would REAL*4, with its LSB relative error of about 10^-7, not be
> adequate for most physical computation? I sure never measured anything
> to even remotely that precision...

Modern electronic structure calculations for quantum mechanical modelling
of molecules and solids need far more than this.  It's a fairly large
application area with many codes such as CASTEP, CRYSTAL, ABINIT, GAUSSIAN,
GAMESS, WIEN2K and many, many more.

A typical example of a fairly recent (smallish) calculation of mine
calculates the total energy of a 17-atom system as around -3000 eV, and
I am interested in energy differences of 1 meV, a required resolution,
of 3 parts in 10**7.  Now this calculation did not even include the
atomic-like core electrons (it used pseudopotentials, for those who
know the field).  Fully all-electron calculations on large systems
containing heavy atoms can require 3 or 4 orders of magnitude more
resolution than this, and in some circumstances ieee double precision is
barely precise enough to perform the calculation avoiding round-off error.

These types of calculations can take hours or days on massively-parallel
supercomputers, so the performance hit of software MP arithmetic is
far too large a slowdown to be useful.

Keith Refson

-- 
Dr Keith Refson,
Building R3
Rutherford Appleton Laboratory
Chilton
Didcot                       kr AT
Oxfordshire OX11 0QX         isise D@T rl D.T ac D?T uk

jvorbrueggen@not-mediasec.de writes:

>>>> Yes, but usually the computational error is smaller than other
>>>> sources of error.  When they're not, higher precision is necessary. I 
>>>> rarely use REAL*4 for the physical problems I deal with.  REAL*8
>>>> is almost always adequate.

>>> But why would REAL*4, with its LSB relative error of about 10^-7, not
>>> be adequate for most physical computation? I sure never measured
>>> anything to even remotely that precision...

>> Relative error grows. 

> Of course, that was the whole point of my answer to tholen! He was/is 
> claiming, on the one hand, that computational error accumulation can be 
> ignored,

I made no such claim.

> and then, on the other hand, suddenly said that he almost always uses 
> REAL*8 instead of REAL*4.

You say that as if there is supposed to be some connection between the
two.  I use REAL*8 because most of the problems I deal with high
precision.  But the uncertainties in those numbers are still larger
than the quantization noise.

> But we already knew he was inconsistent.

You're erroneously presupposing that I'm being inconsistent.  Hell, you
can't even comprehend what I've written, as evidenced by your allegation
that I said that computational error accumulation can be ignored.  What
have you been smoking?

> And with regard to the other replies: Yes, I know about g-2, and some other 
> examples for high-accuracy measurements. The astronomical one is actually 
> quite interesting: Various compound values, in particular GM for various 
> heavenly bodies, are known very well, as they can (and need be) measured to 
> high precision for navigation. G, on the other hand, as one of the fundamental 
> constants, is only known to 10^-3 or so, and likewise the related values for 
> the masses of the bodies.

CODATA gives G to a lot better than 10^-3.  But GM is still known a lot
better.

<tholen@antispam.ham> wrote in message 
news:46a5def2$0$8048$4c368faf@roadrunner.com...
> jvorbrueggen@not-mediasec.de writes:

>> And with regard to the other replies: Yes, I know about g-2, and some 
>> other
>> examples for high-accuracy measurements. The astronomical one is actually
>> quite interesting: Various compound values, in particular GM for various
>> heavenly bodies, are known very well, as they can (and need be) measured 
>> to
>> high precision for navigation. G, on the other hand, as one of the 
>> fundamental
>> constants, is only known to 10^-3 or so, and likewise the related values 
>> for
>> the masses of the bodies.
>
> CODATA gives G to a lot better than 10^-3.  But GM is still known a lot
> better.
I was always amazed at the mosaic that are computations in astronomy.  It's 
hard to get a second opinion from the other side of space.  Dr. Ptak always 
said that getting measurements to within an order of magnitude was very 
good.
-- 
Wade Ward 

Wade Ward wrote:

(snip)

> I was always amazed at the mosaic that are computations in astronomy.  It's 
> hard to get a second opinion from the other side of space.  Dr. Ptak always 
> said that getting measurements to within an order of magnitude was very 
> good.

There is recent discussion on the number of universes, with the
range between 1 and 1e500.

That high end comes from the probability of the physical
constants of the universe having the values that they have,
and that allow for us to be here.

-- glen

On 2007-07-25 00:41:22 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

> Wade Ward wrote:
> 
> (snip)
> 
>> I was always amazed at the mosaic that are computations in astronomy.  
>> It's hard to get a second opinion from the other side of space.  Dr. 
>> Ptak always said that getting measurements to within an order of 
>> magnitude was very good.
> 
> There is recent discussion on the number of universes, with the
> range between 1 and 1e500.
> 
> That high end comes from the probability of the physical
> constants of the universe having the values that they have,
> and that allow for us to be here.
> 
> -- glen

I repeatedly heard the comment that in astronomy orders of magnitude errors
often refer to the exponent. From 1e0 to 1e500 here fits the comment.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:_-2dnbIlBswMKjvbnZ2dnUVZ_jGdnZ2d@comcast.com...
> Wade Ward wrote:
>
> (snip)
>
>> I was always amazed at the mosaic that are computations in astronomy. 
>> It's hard to get a second opinion from the other side of space.  Dr. Ptak 
>> always said that getting measurements to within an order of magnitude was 
>> very good.
>
> There is recent discussion on the number of universes, with the
> range between 1 and 1e500.

So somewhere "out there" there is another universe with another "me" who 
didn't invite me to his wedding!
(with apologies to Terry Pratchett and his "Discworld" books :-) )

Les 

>I knew Fortran is an old programming language, but this is...
>surprising.
>
>Shouldn't it have Latin keywords (FINIS FACENDUM instead of END DO).

Only when used on calcium-based monolithic computers for calculating.
Then the calculi rule ;-)

On Jul 16, 12:28 am, robert.corb...@sun.com wrote:
> On Jul 15, 8:15 pm, nos...@see.signature (Richard Maine) wrote:
>
> > <snip>
>
> > > 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.
>
> > I see no wording that says "the same" or anything like that.
>
> No, but I see the phrase "the representation of a positive or zero
> internal value."  It certainly seems to me that establishes that
> they are treated the same.
>
> <snip>

FWIW I consider the phrase "the representation of a positive or zero
internal value in the field may be prefixed with a plus sign" to be
ambiguous. If the phrase were instead "the representation of a
positive or zero internal value in the field may both be prefixed with
a plus sign" then it would require the same treatment for both sets of
values, while the phrase "the representation of either a positive or a
zero internal value in the field may be prefixed with a plus sign"
would have the meaning the committee has chosen.