Re: On writing negative zero - with or without sign

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?

.

Relevant Pages

  • Re: How do you keep track of what all the numbers mean?
    ... that if you develop a floating point representation of a system, ... but I would suspect that scaling constants is a main part of it. ... There will be an assumed scaling between the floating point ... will depend upon the input signal power. ...
    (comp.dsp)
  • Re: Rounding of the double
    ... John von Neumann suggested that only fixed-point integers should be used because floating ... If you choose your representation as double, then you have to live with the consequences. ... you can never get precision in any computation on a computer than involves ... MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text - ...
    (microsoft.public.vc.mfc)
  • Re: This calculation is just wrong / computer cant count!
    ... we have is the binary representation of the computer. ... your delusional system of mathematics, one based on a decimal arithmetic model, is ... "ignore" any aspect of floating point precision. ... "I do not wish to deal with the inherent inaccuracy of double precision floating point. ...
    (microsoft.public.vc.mfc)
  • Re: How do you keep track of what all the numbers mean?
    ... that if you develop a floating point representation of a system, ... but I would suspect that scaling constants is a main part of it. ... There will be an assumed scaling between the floating point ... So, in my LMS equalizer example, if my floating point equalizer input ...
    (comp.dsp)
  • Re: Gentler Decimal Floating-Point
    ... effectively change the radix of a decimal floating point ... under the heading "Logarithms all the time", ... logarithmic representation of numbers to be made workable for all the ... The middle digits are shifted only when the exponent, ...
    (comp.arch.arithmetic)