Re: Why (IMO) you should vote Yes to Motion 14.02
> Date: Tue, 29 Jun 2010 22:18:04 +0200
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Why (IMO) you should vote Yes to Motion 14.02
>
> Zitat von Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>:
> >>
> >> . . .
> >>
> >> datum. Additionally it mentions multi-precision representation of
> >> intervals by the triple (x_hat, delta_l, delta_u) to be
> conforming.
> >
> > It mentions this in the informative note. There is
> > nothing more going on here than that it is the intention
> > that such a format MAY BE made to conform &, as such,
> > should not be excluded.
> >
> >> Therefor a mid-rad representation seems to be conforming to these
> >
> > Just so, with some caveats.
>
> This may be nitpicking, but 6.1 doesn't say anything about the level 2
> datum it describes as being represented. You might infer from the
It says "An implementation may choose any means to represent a
level 2 interval datum..." & in the next paragraph "A concrete
interval format... (is a mapping) ...to an associated level 2
format."
That's all.
Everything else is an informative note until you get to 6.2
which is about containment in format conversion.
> notation that this has to be an interval with bounds in F, but that's
> not explicit in the text, is it? Therefor my note that the text itself
You might make such an inference but, as you imply, it would be
inferring a bit too far. The text says only "that it shall be
possible to retrieve the bounds of x exactly."
Thus some form in which the bound may be recovered by, x + eps
or even x + x*eps would be acceptable so long as those
operations can be performed exactly.
This would seem to include both mid-rad forms & others (say a
midpoint & a RELATIVE radius) so long as care is taken that
only elements for which exact extraction is possible are
considered members of the set.
As I mentioned in my previous note, this puts some burden on
the mid-rad form. The statement about exact bounds on not
trivial. But I gave an example in which it might turn out to
be cheap. I don't know if that will end up being acceptable
to the mid-rad people or not.
My hope is that they will not reject it out of hand but
consider it long enough to come up with something better.
> doesn't exclude mid-rad. The mention of the note about the triple
> representation was to underline that a present note includes the
> possibility that the bound is exactly represented by a sum of two FP
> numbers with no requirement---besides notation and the nature of the
> level 2 datum---that this sum is itself an FP number. But as already
Close.
The "Multi-precision interval packages..." example in the note
includes the possibility that the bound is EXACTLY represented
by a sum of 2 FP numbers with no requirement---besides notation
& the nature of the level 2 datum---EXCEPT FOR THE REQUIREMENT
that this sum itself be an FP number.
> put this is nitpicking and we shouldn't use it to justify support of
> formats but cater the wording to our decision.
>
> Cheers,
>
> Christian
On the contrary, this is not nitpicking.
Indeed, you have put your finger on the crux of the matter.
The exact bounds requirement places a burden of care on a
mid-rad or similar form that IF they are going to use an
arithmetic operation to recover the bounds of an interval
THEN that operation shall be exact.
If that means that the precision of the recovered bound is
so wide as to be able to extract the bounds of all possible
(mid x rad) pairs exactly, then that works.
If not, then the set of all (mid x rad) pairs needs to be
restricted to some subset such that exact extraction is
possible.
mid <-- mid
rad <-- roundAway(mid + rad) - mid
is one such subset.
As for "justifying the support of formats" versus "catering
to the wording", you have a real decision to make here on
the merits not just the words.
The text is non-vacuous. It DOES have meaning that has
implications on acceptable mid-rad forms. It makes it
POSSIBLE for them to conform but non-trivial.
Therefore, there is a real decision to be made here: Are we
to require that a conforming interval implementation never
lie to (or mislead, to be less pejorative) our users by
telling them that two DIFFERENT intervals are identical or
are we to permit that to happen for the sake of accepting
the mid-rad (& other) forms without any care taken to
prevent it?
It is a hard decision & I don't expect all to see it the
same way. But it is a decision we must make.
As for the wording...
I have had 7 years of wordsmithing from people who were
trained in math & engineering rather than words. It is
a complete waste of time.
This committee would serve itself well if all wording
decisions were left up to the editor & no one else. It
is OK if a member objects to some wording but it should
be left up to the editor whether or how it is to be
changed. And voting no unless a word is changed is a
foolish vote. If you are going to vote no because of the
wording it should be because of the agreed upon MEANING
of those words not some obtuse possible interpretation.
Really, spending our time arguing wording will mean
spending years in purgatory before we reach our final
destination.
Whatever that turns out to be... :-)
Dan