Re: Motion 30, Constructors
> Subject: Re: Motion 30, Constructors
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Tue, 10 Jan 2012 16:41:05 +0000
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear P1788
>
> I'm hopefully getting back to work after a bug that has laid me low for two
> weeks. I asked Baker to defer the voting period a bit. Here are comments on
> some of the discussion on this motion.
>
> (A) Status of modal (Kaucher) intervals
> ---------------------------------------
> I know some people would like the standard to have no provision for modal
> intervals, but they ARE of commercial significance as Sunfish's applications
> show, and deserve respect. Strategically, I continue to believe that they
> should be an optional extra, and that a natural place for their specification
> is in an Annex (appendix) labeled as "informative".
>
> I think they should have the same status as the Recommended Arithmetic
> Operations, and any other specification in P1788 that we call "informative".
> I believe this is:
> - A conforming implementation needn't implement this feature.
> - If it does, it needn't do so exactly as described.
> - But it's probably dumb, NOT to do it exactly as described.
>
> We COULD invent some other status, such as "you don't have to implement this,
> but if you do it as described, your implementation conforms to P1788-PLUS"
> (or whatever). By the Occam's Razor principle -- an aspect of K.I.S.S. --
> I prefer not to do such things, or not till we reach a final tidying up phase
> of P1788. Dan Zuras, can you advise?
I think this is an excellent approach John. Your analogy
with optional clause 9 of 754 is a good one. Each of the
functions described there may be individually included or
not, as the implementer wishes. But if included they must
behave as described.
There is a minor difference you might wish to consider in
our case. It may be the case that the modal functions
described make no sense unless they are all included in
a coherent package. If so, language that specifies that
should be included in the annex.
>
> Alexandre Goldsztejn may be preparing a "modals: in or out?" motion, which
> would help settle this.
Some have pointed out that there are other approaches to
the functionality provided by modal intervals. If that
is so, let me suggest that this motion might be best
couched in terms of "modals or the other guys, which
shall we bless?".
My reasoning for this is that it would be confusing at
least & inconsistent at most if we had language & functions
for supporting more than one approach. So lets bite the
bullet now & decide on a single approach that we think is
best for the future.
>
>
> (B) Constructing bare or decorated intervals?
> ---------------------------------------------
> I regard decorations, in whatever eventual form, as solidly in Level 1. A
> reason to have them there is that then, an interval algorithm written at the
> mathematical level *may* (but doesn't have to) express exceptional behaviour
> in terms of decorations, thus making it easier to transcribe to executable
> code.
>
> A second reason is that Level 2 is basically about implementable, finite
> precision, algorithms. The decorations we shall probably (IMO) choose, e.g.
> "everywhere defined", have meaning whether are not precision is finite. So
> why lump them in to Level 2? (Compare IEEE 754, where 3 of the 5 flags are
> essentially about finite precision.)
>
> Then, a *decorated interval* constructor at Level 1 can handle failure (i.e.,
> invalid data) with no bother -- we return some decorated object that
> indicates this, which we may choose to call NaI. It may come in more than
> one flavour.
>
> However, failure of a *bare interval* constructor is what raised my question:
> On 3 Dec 2011, at 09:12, John Pryce wrote:
> > When a constructor call "fails", should the call
> > (a) return Empty, as currently written;
> > (b) return a "Not an Interval" value, which must then exist at Level 1; or
> > (c) not return any value, i.e. the function is simply undefined at this
> input argument?
> Another option, which Dan has favoured: Bare interval constructors don't
> exist, one can only construct decorated intervals.
Arnold suggests that not having bare interval constructors
is the way to go here. I agree, with the caveat that we
must go slightly further: We must not define any function
that results in a bare interval.
John, I agree with your characterization of decorated
intervals as solidly at level 1. With this approach, bare
intervals are level 3 objects at most.
But we need not leave them to the inconsistent whims of
our implementers. This could be the topic of another
informative annex. Something like "Bare intervals for
fun & profit" or "How to beat the competition by
eliminating decorations when they are not needed".
If someone believes there are standardizable approaches
to the sort of optimizations that bare intervals afford
the implementer, they can be described in this annex.
If not, maybe we shouldn't mention them at all.
Once again, you guys are better qualified to decide this
than I am.
>
> . . .
>
> John Pryce
The only other comment I have is about NAIs.
In 754, NaNs are a necessary evil. But they ARE evil.
They are the STDs of floating-point in that once one
appears they spread repidly until they infect everything.
In 1788, I believe we have the chance to avoid NAIs. The
canonical case is [0,0]/[0,0]. In floating-point, 0/0 must
return the least confusing floating-point object which is
a NaN. But in the intervals [0,0]/[0,0] can return empty
which is ALSO the least confusing answer. For all things
that exist at level 1 I think there exist rational answers
within the set of extended Real intervals.
Still, one might want NAIs to exist. But, in analogy to
bare intervals, they might only exist at a level that is
hidden from the user. That is, an NAI might only come up
during the moral equivalent of an assertion failure. A
bug, perhaps. Or a repairable error. I don't know. But
if we confine their use to diagnostic only & only for the
eyes of the implementer, I think we will do our users a
great service.
As always, IMHO.
Yours,
Dan