Re: Clean Object Class Design -- Circle/Ellipse

From: Jan Hidders <hidders_at_REMOVE.THIS.win.tue.nl>
Date: 7 Aug 2001 19:49:25 GMT
Message-ID: <9kpgo5$4ag$1_at_news.tue.nl>


Mikito Harakiri wrote:
> In article <9koatn$6q$1_at_news.tue.nl>, Jan Hidders says...
> >
> >Mikito Harakiri wrote:
> >>
> >> I would suggest I[Real,Integer] mapping any real r into integer i as
> >> follows:
> >>
> >> i = floor(r)
> >
> >That would be the wrong way around because then you would try to
> >make the Reals a subtype of Integer.
>
> Yes it looks odd, at first, because my conclusion is that model A is
> a sybtype of the model B when B's universe is a subset of A's one!
> Yet again, our primary concern here is substutability, not set
> inclusion. Being able to substitute a model means that B must have
> 1. operations with the same signature as A
> 2. semantics of operations on B must be "consistent" with that of A

Ok. Agreed. Although the "consistent" might need some clarification. And I believe that the "semantics should be independent of type" definition I gave is probably a good formalization of that.

> >It looks a lot more difficult then it really is. Suppose you have the
> >integer plus (I+) and the real plus (R+), and the (in some sense)
> >trivial mapping I[Int,Real] : Int -> Real, then it says that 1 + 1
> >has always the same meaning, i.e., the result is the same if I first
> >convert the 1's to 1.0's and then use R+ or if I immediately apply I+
> >and convert the result to a Real. In formulas:
> >
> > I[Int,Real](1) R+ I[Int,Real](1) = I[Int,Real](1 I+ 1)
>
> Here you did exactly what I asked. Just add a disclamer:
> "where '+' is any operation, and 'Int', 'Real' are 2 arbitrary domains". It
> requires some reader's imagination to extend it to n-ary operations, but it's
> cheap generalization, anyway.

Exactly. Sorry for making things more complicated than necessary.

> >> With "I" being i = floor(r), couldn't reals be a subclass of integers?
> >
> >Well, let's see, it should hold for all Reals x, y that,
> >
> > floor(x) I+ floor(y) = floor(x R+ y)
> >
> >Yes, it holds, so they could, if this is your only operator. :-)
>
> You mean '+' is my only operator? I see that I can't make it
>
> floor(x) I* floor(y) <==> floor(x R* y)

I don't think you can fix this. Let's abbreviate the interpretation function to 'f', then it must hold that

  f(x) I* f(y) = f(x R* y)
  f(x) I+ f(y) = f(x R+ y)

By the group properties you know that f(0) = 0.0 and f(1) = 1.1, and then it follows that f(x) = x for all integers. So what about fractions like a/b? You know that a/b * b = a. So f(a/b) I* f(b) = f(a/b R* b) becomes f(a/b) I* b = a and so f(a/b) must be an integer that multiplied by b gives a. Somehow I don't think you are going to find such an integer for every a and b. :-)

> >But.... usually you also have an equality operator R= : R x R -> Bool
> >and I= : I x I -> Bool and then it should also hold that,
> >
> > (floor(x) I= floor(y)) = (x R= y)
> >
> >and that doesn't hold. So if you have equality operators (and you
> >almost always have) then the interpretation function I[SubDom,SupDom] L
> >SubDom -> SupDom must be injective.
>
> Couldn't the condition be relaxed to just
>
> (floor(x) I= floor(y)) <== (x R= y)

No, because then the semantics of an expression like "1.0 = 1.1" would have different semantics, depending upon what type you assign to the numbers.

-- 
  Jan Hidders
Received on Tue Aug 07 2001 - 21:49:25 CEST

Original text of this message