Re: On trits & tetrits...
Not quite, Nat.
Its kind of the set theoretic equivalent of the
fundamental theorem of interval arithmetic.
While it is true that assertions on the empty set are
vacuously true, we are not gathering assertions.
We are mapping the function P(f,x) onto the elements
of the set {true, false} FOR ALL x in xx. Thus, the
definition:
decorationP(f,xx) = { P(f,x) for all x in xx }
must have the result {} (the empty set) if there are
no elements in xx because it must be true that:
decorationP(f,xx) \contained decorationP(f,yy)
for all xx \contained yy.
In particular, we must have that:
decorationP(f,[empty]) \contained
decorationP(f,xx) \contained
decorationP(f,[entire])
for all f & for all xx.
Since the empty interval is trivially contained in all
intervals we must haved that decoration(f,[empty]) = {}
(the empty set).
Don't you agree?
Besides, it gives us an easy way to test for empty
intervals.
Dan
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>,
> "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: On trits & tetrits...
> Date: Fri, 9 Apr 2010 15:04:20 -0500
>
> I agree, Dan.
>
> It is a clear way to explain the meaning of the "possibly" state of a trit.
> P(f,xx) is a proposition. All propositions must be true or false. So
> decorationP(f,xx) = { P(f,x) for all x in xx }
> I believe is exactly correct.
>
> However, there is no 4th possibility, i.e.,
> inDomain(sqrt,[empty]) = {} (the empty set)
> is wrong, because no proposition is the empty set. Instead, we must have
> inDomain(sqrt,[empty]) = { true }
> since any statement/assertion about the empty set is always true. See, for
> example http://en.wikipedia.org/wiki/Vacuous_truth.
>
> Nate
>
>
> ----- Original Message -----
> From: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Sent: Friday, April 09, 2010 11:48 AM
> Subject: On trits & tetrits...
>
>
> > Folks,
> >
> > The other day John mentioned thinking about an interval
> > relation as a mapping of xx R yy onto a subset of the set
> > {true, false}.
> >
> > Then today, he gave us version 2.2 of the draft & I paused to
> > look at the definition of trits in the section on decorations.
> >
> > And I had an idea.
> >
> > I have to tell you that I have always been bothered by the
> > value 'possibly true'. It is not so much that I can't handle
> > a 3-valued logic. It is that everyone speaks differently
> > when they talk about things that return that value. What
> > bothers me is that I think we are all using our own definition
> > of 'possibly' & thinking different things when we discuss it.
> >
> > The idea that struck me is that we might be able to make that
> > notion concrete by considering trits as subsets of {true, false}.
> > (This may mean that they will actually be tetrits but let's pass
> > on that until later.)
> >
> > First, consider that a decoration is some property P of some
> > function f such that P is either true or false when evaluated
> > at some point x. So, for example, if P = inDomain, f = sqrt,
> > we have that inDomain(sqrt,-1) = false & inDomain(sqrt,1) =
> > true.
> >
> > Now, to make it concrete for intervals, let us define the
> > evaluation of P on an interval xx as that subset of {true,
> > false} we get when we evaluate P(f,x) for all x in xx. That
> > is:
> >
> > decorationP(f,xx) = {P(f,x) for all x in xx}.
> >
> > So, for example, we have:
> >
> > inDomain(sqrt,[0,1]) = {true}
> > inDomain(sqrt,[-1,1]) = {true, false}
> > inDomain(sqrt,[-2,-1]) = {false}.
> >
> > That is, the interval [0,1] is entirely contained within the
> > domain of sqrt, [-1,1] has points both in & out of the domain,
> > & [-2,-1] is entirely outside the domain.
> >
> > (Looks useful for divide & conquer, does it not? :-)
> >
> > Under this interpretation, a decoration may be considered true
> > if the evaluation of that property on that function is always
> > true for that interval (i.e. evaluates to {true}). It is false
> > if it is always false (evaluates to {false}). And it is the
> > third value (possibly true, trueFalse, whatever) if it is
> > sometimes true & sometimes false (evaluates to {true, false}).
> >
> > This would be easy to implement. We could store the value of
> > a decoration as two bits, one for the false value & the other
> > for the true value. Say, for inDomain, we might have:
> >
> > inDomainFalse = There exists x in xx such that
> > inDomain(f,x) is false &
> > inDomainTrue = There exists x in xx such that
> > inDomain(f,x) is true.
> >
> > The careful reader will notice that there is a 4th possibility.
> > We might have inDomain(sqrt,[empty]) = {} (the empty set). This
> > could happen during the evaluation of the empty set for just
> > about any property for just about any function. It could also
> > serve as the default (or initial) value for constructors,
> > depending on the property.
> >
> > Does this sound good to anyone?
> >
> > While it simplifies the thinking about decorations for me, I
> > must confess that it loses the 'stickyness' property that some
> > people may be counting on for tracking decorations as if they
> > were exceptions. This may be important. If it is we may need
> > another bit to track it for each property.
> >
> > Anyway, I just thought I'd try to start a discussion on the
> > subject. I have no specific motion at the moment. Perhaps
> > one will come out of the discussion.
> >
> > There you go folks, enjoy...
> >
> >
> > Dan
> >