Dan Zuras writes:
Nate,
I have proposed a method several times now but I will
state it once again, narrowly expressed to address your
concern.
...
Are there any more questions or doubts that it can be
done?
Deciding whether or not it is the RIGHT thing to do
is really up to you.
Dan,
Thank you for the clear explanation.
I get it.
Let me try to frame my point better as a follow-on to Baker's e-mail.
(also, I know I said I was going to shut-up and listen, but now two
people
have addressed me specifically...)
Baker Kearfott wrote:
Nate,
On 6/30/2010 16:42, Nate Hayes wrote:
.
.
.
It all hangs together for me until mention of extracting bounds of the
Level 2 interval losslessly as a floating-point number. I don't see
how
a mid-rad implementaiton (or even some of the other examples you gave)
could conform to that.
It seems to hinge on what objects we are talking about. Take complex
intervals (which probably are outside the scope of 1788, at
least for now, but which illustrate the point): The mid-rad
representation
gives a different set of objects than the inf-sup representation.
For real intervals, we can think of mid-rad at level 2 as
giving a different set of objects than inf-sup, just as we think
of binary and decimal floating point data as different sets. We
can then talk of unique and lossless representation, within the
particular set of objects. Also, conversion between the different
sets then takes on the character of conversion between, say, binary
and decimal, and we could specify, say, that the conversion be
the tightest possible result, if we wanted. We could also specify
the mid-rad result of an operation in, say, mid-rad
as being, say, the tightest possible
superset of the true result within the set of floating point
intervals represented in mid-rad form.
Yes, precisely.
The standard can dictate
"smallest superset," (or whatever we deem appropriate)
independently of whether we the set of interval objects is
defined by mid-rad or inf-sup over the underlying floating point
objects. (The underlying objects perhaps do not even need to be
floating point, but I'm assuming for now that their cardinality
is finite.)
Yes, I completely agree.
Sorry to be a buzzkill, but I guess I'm a little lost.
Did I clarify?
This articulates very well and precisely the part in my mind that
"all hangs
together," mentioned above. I would not change a jot or tittle.
But notice something: even though you describe a way to talk about exact
representation of Level 2 intervals in a typeless manner (which is good,
IMO), nowhere in your explanation did it require that extracting an
endpoint
of a Level 2 interval losslessly as a floating-point number is
required or
even always possible. For example, you provided suitable definitions
for all
we hope to accomplish simply in terms of "tightest possible
superset," etc.
Let's take a closer look:
(for the sake of having a concrete discussion, I like to speak
specifically
again about Level 1 and Level 2 inf-sup and mid-rad intervals. This
is just
for illustration and discussion, ok? So Dan, please indulge me).
If we have Level 1 inf-sup interval [a,b] and Level 1 mid-rad interval
(m;r), with m=(a+b)/2 and r=(b-a)/2, then we also have Level 2 inf-sup
interval [A,B] and Level 2 mid-rad interval (M;R), each the tightest
possible superset such that [a,b] \subset [A,B] is true and (m;r)
\subset
(M;R) is true. Generally speaking, it may not be the case that A=M-R or
B=M+R, however this is no problem, since at Level 1 [a,b] \subset
[M-R,M+R]
will always be true (please pay special attention to the case, and
note that
I'm assuming so far all arithmetic is calculated with infinite
precision).
This agrees with the statement "we can think of mid-rad at level 2 as
giving a different set of objects than inf-sup, just as we think of
binary
and decimal floating point data as different sets".
So far so good. It all hangs together.
However, if we require the endpoints of any Level 2 interval must be
extractable in a lossless manner as a floating-point number, this
implies
A=M-R and B=M+R must both be true. But these equalities may not
always hold.
It may even be possible that there does not exist any such
floating-point
numbers M-R or M+R. These numbers M-R and M+R might only exist at
Level 1
when the arithmetic is performed in infinite precision.
HOWEVER:
As Dan explains in is e-mail:
It sounds complicated but its not, really. If I have
a Real level 1 interval for which the Real midpoint is
midR& the Real radius is radR, I can use the subset of
mid-rad elements defined by the assignments
mid<-- roundToNearest(midR)
rad<-- roundAway(mid + radR) - mid.
Not all mid-rad pairs have the property that they can
be summed to an element of F exactly, but THIS SUBSET
of the mid-rad pairs DOES have that property, by
construction.
...
And it doesn't solve everything.
It will often return an interval that is slightly wider
than would be returned in an inf-sup form but only by
an ULP on one side or the other. This will piss off
the inf-sup guys who want narrowest interval uber alles
(no nationality dig intended :-) but it is the price of
freedom from concern about the nature of the format.
My point is this: WHY do we even need to make these restrictions and
compromises, when everything we already hope to achieve is already
specified
by simply saying something along the lines:
"The Level 2 result of an operation is the tightest possible superset
of the
true result within the set of floating-point intervals represented by
the
Level 2 type."
This may potentially result in some widening when converting from
mid-rad to
inf-sup. But it doesn't require any restrictions on mid-rad Level 2
objects,
and Dan's solution causes widening in this case anyways.
Nate