Re: Discussion paper: what are the level 2 datums?
John Pryce wrote:
I submit the attached paper for discussion, following which I aim to make it a motion.
I believe that all issues discussed in this paper are already covered
(and in a better way) by Motion 8, except that perhaps some clarifying
details were missing.
Thus a motion on it should be superfluous.
1. The first point, made already by Nate Hayes, is that Motion 8 was the
result of a careful analysis of the NaI problems discussed in earlier
motions that didin't succeed or were withdrawn (don't remember which).
As a result, the bare decorations of Motion 8 replace the NaI(s),
forming a full substitute for NaI(s). They cater for the need to
discriminate between various versions an interval can deteriorate
to what earlier was a NaI.
Note that bare decorations are _not_ intervals, hence are not
represented by the interval format, and do not have a bare and a
decorated version.
2. According to Motion 8, the object xx created by a string s passed
to an interval constructor xx=interval(s) when s does not denote a
valid interval -- i.e., what you call NaI -- does not contain a real
number. Hence, according to Motion 3, it must have Empty as interval
part. By the semantics of the ''Valid'' trit, it has notValid as
decoration part.
This is simply part of the definition of the interval constructor
(which we forgot to specify in Motion 8).
Thus what you call NaI has, according to Motions 3 and 8, the unique
decorated representation NaI = (Empty,notValid).
In particular, bare(NaI)=Empty, without having to design special rules.
But I do not see any incentive to call this a NaI, since it is a
decorated interval, one of many possible ones that also do not have
a special name.
3. Concerning the values of the other decoration trits, I think that
this is part of a general observation that not all combinations of trit
values make sense. Indeed, assuming the four trits
v=valid, d=-defined, c=continuous, b=bounded
(which are the indispensible ones) and the possible values
+ (True), - (False), and 0 (no claim),
only 10 combinations of trits are computationally relevant and should
be allowed:
v d c b | #cases
- 0 0 0 | 1
+ - 0 0 | 1
+ 0 0 0- | 2
+ + +0 +0- | 6
(In particular, v is never 0 and c is never -.)
For example, the reason for excluding the case + 0 0 + is:
If something is possibly undefined, how can it be surely bounded?
How can undefined things have any property?
We need the vd decorations for constraint propagation and the vdcb
decorations for existence tests. Now it seems to me that neither of
these can make use of cases not in my table. Lacking other uses
of the decorations, we need not complicate things that improve
the available information in marginal cases only.
(Actually, I do not really care how the decorations are defined in
the standard, as long as the definition is simple and unambiguous,
and lets one correctly recognize the cases v=d=c=b=+ needed for
existence theorems and d=-0+ if v=+, needed for set covering.
So from my perspective, one would only need to distinguish the five
cases -000, +-00, +000, ++00, ++++, and widen the other cases into
the appropriate relaxation. But any refinement of these would be ok.)
4. Regarding your Section 1.4, we haven't yet decided anything about the
behavior of inf, sup, mid, rad. This should be a separate motion that
defines these everywhere - not just for (Empty,notValid).
My proposal is to ignore the decoration, and to use the formulas from
the Vienna Proposal otherwise (cf. Sections 2.5.9, 2.5.120, and 5.2
there).
The only reasonable alternative I can see (but do not propose to use)
is the treatment of Empty, where (at the expence of more complex
executing formulas) one could sensibly argue to take
inf(Empty)=+inf, sup(Empty)=+inf, mid(Empty)=0, rad(Empty)=-inf
in place of NaN for all four results.
Arnold Neumaier