Re: DirectedInf
Dan Zuras Intervals wrote:
Date: Sat, 09 Oct 2010 12:48:28 +0200
From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
See Section 7.8 for the motivation, and Sections 7.[1245] for the
proposed behavior.
I'll reconsider Chapter 7 of the Vienna Proposal in the next few weeks,
trying to make it fully 754 compatible in the light of the nearly but
not fully closed door we had discovered.
Restricting +0 for lower bounds & -0 for upper bounds
is OK.
Section 7.1 uses the term 'exact zeros'. I will assume
this is meant to distinguish a zero bound which is
arrived at exactly from a zero bound which is arrived
at via underflow. While it is a distinction I once
suggested we make in a decoration, just what new
behavior did you have in mind for exact zeros that
would be at odds with 754 section 6.3?
I need to reconsider everything, and this needs leisure I don't
have at the moment, due to other commitments. So it may take a
week or two....
In 7.2 you have 0*oo = 0. This is outside 754 in that
the operation is invalid (i.e. returns a NaN). However
it has been my opinion in the past that it would be OK
to replace this with zero (if that is INDEED the correct
answer) as a special case. If you are proposing a new
interval only rounding mode that does this, I'm OK with
it.
Yes, something like this is intended. When Chapter 7 was written,
I didn't know that one could add rounding modes, hence hadn't
considered the implications. Will do that soon.
In 7.3 I'm less sure that you can claim that oo-oo
should be zero. But if you can, I'm OK with it. Shouldn't
oo-oo be -oo for a lower bound & +oo for an upper? How
can anything else contain the result?
The point is that inf is a bound, not a number. This allows
exceptional behavior without violation containment.
Come to think of it, in the last case shouldn't 0*oo be
-oo for a lower bound & +oo for an upper?
I'll check in due time; I can't remember my old arguments ave need
redo everything.
7.4 & 7.5 0/0 = 0 rather than NaN, the same as the others.
Once again, -oo for lower & +oo for upper? But if you know
its right, OK. We should never run into NaN/0 but if we
do I cannot see anything other than NaN being correct.
We do, for Empty/0, but there the result is ok.
7.6 Again, I don't see how you can argue that (+/-oo)/(+/-oo)
= +/-1 rather than +/-oo depending on the bound but if you
can I don't see any violation for some rounding mode outside
the standard. I hope that x/oo = 0 for all finite x. Kind
of an infinite signum function, ain't it. :-)
I need to check for the sign propagation....
7.7 In floating-point applications I have been fighting a
losing battle over the years to NOT eliminate denorms (now
known as subnorms). But as intervals are only interested
in containment, flushing to zero & still containing the
answer is pretty nearly as accurate as going through the
subnorms. It is not scale free (which is the main problem
with flushing in floating-point) but perhaps that doesn't
matter as much to you guys. BTW, use subnormal. The
term denormalized is deprecated since 754-2008.
7.8 I'll take your word for it here. I won't check your
cases.
Really, if this is all you have in mind for a new rounding
mode (or a pair of them) all this is fine.
It is such things - variations of what it already there now.
It is the new NaNs I balked at. Not the new rounding modes.
I believe that everything will work out well in some way or another,
and will find out how.
But I need time to ponder the options and how things best work together.
Arnold Neumaier