Re: A question Re: Level 1 <---> level 2 mappings; arith
Dear Nate,
I disagree when you say:
"These numbers M-R and M+R might only exist at Level 1"
Level 1 is IMO a mathematical abstract level.
Hence no specific sets (of intervals) should be
specified at level 1 but just the algebraic properties
of the (interval) spaces with the rules for the
operations and relations in these spaces.
An abstract definition of an (interval) space is axiomatic,
based on rules for the assumed operations and relations on
abstract (interval) objects. Such definitions are well-known
in the interval literature. The sets of mid-rad and
inf-sup intervals are special cases of such abstract sets.
It is natural that these sets can be different specific
cases of such sets. For example, both integers and rationals
make a group, both rarionals and reals make a ring, etc.
Hence IMO the discussion whether infinite intervals
are compulsory or not is not part of level 1. Neither is
the discussion on the mid-rad or inf-sup presentations.
These discussions should be shifted to the next levels.
Svetoslav
On 30 Jun 2010 at 19:56, Nate Hayes wrote:
Send reply to: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
To: <rbk@xxxxxxxxxxxxx>
Copies to: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>,
"P-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: A question Re: Level 1 <---> level 2 mappings; arithmetic
versus applications
Date sent: Wed, 30 Jun 2010 19:56:53 -0500
Organization: Sunfish Studio, LLC
> 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