Re: DirectedInf
> Date: Sat, 09 Oct 2010 12:48:28 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: DirectedInf
>
> . . .
> >>>> But the same hardware can be used with a switch of rounding modes,
> >>>> and the exceptions can be handled as required for fast interval support.
> >>> One thing that still worries me is that in Vienna Proposal it appears
> >>> the method requires that -0 and +0 are not aliases of each-other.
> >> Why is that an obstacle?
> >
> > Well, you know I disapprove of creating new values for NaNs.
> >
> > But as far as 754 is concerned, so long as the arithmetic
> > for zero is done as specified & +0 compares equal to -0,
> > I don't see a problem.
>
> Are there requirements on the behavior of +-0 that must be respected
> for arbitrary rounding modes (i.e., beyond the modes specified by 754)?
Nope. I think you're OK there. The rules are very
carefully spelled out for each operation & each
rounding mode but I guess you're on your own in a
new rounding mode.
Except for +/-0 (op) NaN = NaN for all (op)s. That
is in the NaN section & has no modification for
rounding modes. If you keep that true you're still
OK.
I once delivered a lecture with the title "2 + 2 = 5
for large values of 2 & small values of 5". I stole
the title from another guy. But I was talking about
roundoff error & my listeners got it.
If you wanted to create a new rounding mode in which
this was literally true, I can't see 754 complaining
about it.
So long as no one doing payrolls found out about it. :-)
Well, that & 2 + NaN better still be NaN.
>
>
> > On the other hand, I'm not sure where in Vienna the concern
> > is written.
>
> 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.
>
>
> Arnold Neumaier
>
Let's see...
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?
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. As it does not involve any new values on the
extended Real number line, I see nothing that forbids it.
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?
Come to think of it, in the last case shouldn't 0*oo be
-oo for a lower bound & +oo for an upper?
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.
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. :-)
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 the new NaNs I balked at. Not the new rounding modes.
Yours,
Dan