Re: Proposal: 6NF

On Oct 19, 7:06 am, "vc" <boston..._at_hotmail.com> wrote:
> Jan Hidders wrote:
> > vc wrote:
> > > Jan Hidders wrote:
> > > [...]
>
> > > A much simpler example. Let {0, 1, 2, 3} be a set of four integers
> > > with addition modulo 4. Then, none of its subsets, except {0} and
> > > {0, 2}, retains the addition mod 4 operation which makes the idea of
> > > 'subtype as subset' utterly silly, [....].
> >
> > You keep on making the same mistake. The expression a +[mod 4] b has a
> > well defined result if a and b are from any subset of {0, 1, 2, 3}.
>
> Consider the subset {2, 3}. What is the result of (2+3) mod 4 ? If
> you say it's '1', what is '1'? There is no such element in {2, 3}.

That doesn't matter. The answer is 1. The fact that 1 is not a member of {2,3} is irrelevant. The function +[mod4] still exists, unchanged, even though you took a subset of its domain.

You're conflating math with type issues from OOPLs.

> > > Also, the OOP hypothetical programmer would expect that a subtype
> > > would have, informally speaking, *more*
> > > properties/operations/'methods', not less: the basic class properties
> > > plus some new ones. So at the intuitive level with typical languages
> > > like Java, 'subtype as subset' does not make much sense either, at
> > > least with respect to even the simplest mathematical objects.
>
> > No, also from that perspective it works correctly. The superclass A
> > would contain objects that understand the message plusMod4 with an
> > argument that is in class A and return a result in class A. The objects
> > in the subclass B would also understand this message with an argument
> > in class A and return a result in class A.
>
> Objects in subclass B = {2, 3} won't understand 'plusMod4' because the
> operation does not exist in B, it was lost as soon as you've subsetted
> A = {0,1,2,3}. That is of course if you understand 'operation' in the
> ordinary mathematical sense such that the set is closed under it. If
> you have to go outside the set in question, it ain't no operation no
> more in the accepted mathematical sense.

Certainly they will understand it. Behold:

class ModFour {
  private final int val;
  ModFour(int i) {
    if (i < 0 || i > 3) throw new RuntimeException();     val = i;
  }

  public ModFour addModFour(ModFour a) {     return new ModFour((val+a.val)%4);
  }

  public String toString() { return "" + val; }

}

public class TwoOrThree extends ModFour {   TwoOrThree(int i) {
    super(i);
    if (i < 2 || i > 3) throw new RuntimeException();   }

  public static void main(String[] args) {     TwoOrThree v2 = new TwoOrThree(2);
    TwoOrThree v3 = new TwoOrThree(3);
    System.out.println(v2.addModFour(v3));   }
}

If you run this program it prints "1". Notice that the code doesn't care that addModFour() isn't automatically covariant.

The *only* trouble anywhere in here is if you want to have methods which are mutator methods; that is, methods which modify the distinguished object in place. And yes, in that case, closure is an issue. I have not seen any math books that give functions the same semantics as inherited OOPL mutator methods however.

Furthermore, 2 = 2.0.

Also, I found this equation in a math book on page 3:

  P ⊆ N ⊆ Z ⊆ Q ⊆ R

Marshall Received on Fri Oct 20 2006 - 00:33:15 CEST