Re: Empty interval representations (general)

["Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>]

Dan Zuras Intervals wrote:
> We can represent empties as [NaN,NaN] as I believe Juergen
> & others would have us do, but it does not mean that the
> appearance of [NaN,NaN] means empty. And if we allow such
> things to be propagated without note, they can disappear
> from a calculation which permits empty as a valid
> intermediate result. All without anyone knowing that it
> ever happened.  All without knowing that the rocket is
> about to blow up.


This doesn't entirely make sense to me. Let me parse it out:

At a conceptual level:

   -- Exception handling with decorations provides a mechanism to
distinguish between Empty and NaI; we have this now in P1788 for a while

   -- Tetrits with bool_set semantics improves our ability to make the
distinction even more pronounced

At this level, I don't see how it follows that "if we allow such things to
be propogated without note, they can dissapear from a calculation which
permits empty as a valid intermediate result."

At a bit-encoding level:

Care is needed. But without first having a clear conceptual model in place,
fools rush in!



> If we are to assure our customers of the validity of their
> results we must at least be able to detect when they are
> NOT valid.

Hmm. In Motion 15 this information DOES dissapear from a calculation --
without note. Even at the conceptual level.




> It is for this reason I suggested [+oo,-oo] as a
> representation for the empty interval.  Not because it

> worked out for the comparisons.  That was a (largely)
> lucky accident.  But because it has no NaNs in it.
>
> And if we can define our standard such that every valid
> interval has no NaNs in it, then the appearance of a NaN
> can be detected as an error that won't be ignored.
>
> THAT was why I made the suggestion.
>
> It is ignoring NaNs when they appear that scares me.

Dan, this sounds a little like an articulation of the need for a distinction
between Empty and NaI (or what I might also describe as distinction between
bare intervals and bare decorations). Are you changing your mind?
I'm a little confused.



> Does it not scare you?

Not at the conceptual level of bare intervals and bare decorations, for
example, since none of the things you are afraid of being ignored are
actually ignored at that level.

At the bit-encoding level, I don't know wether to be afraid or not. When I
can see examples how does the implementation fit a specific conceptual
model, this will help. But I'm not sure P1788 has reached a point where we
can really do this, yet.

I still partly think P1788 only needs to specify bit-encodings for
interchange formats and not internal representations of various conforming
implementations.

Nate

P.S. I attach a PDF by Bill Walster on Empty vs. NaI for some perspective.
Not that I do or don't advocate any of it; but perhaps its a reminder on
this topic that we're not the first to kick it around in one form or
another.

Attachment: Empty Intervals.pdf
Description: Adobe PDF document