Re: x*x-1=0

Vadim Tropashko wrote:
> In article <94gv2l$c38$1_at_news.tue.nl>,
> hidders_at_win.tue.nl (Jan Hidders) wrote:
> > >
> > > 0 = empty set
> > > 1 = {0}
> > > 2 = {0,1}
> > > sorry for been off topic here.
> >
> > I don't really see anything wrong with that as long as you keep in
> > mind that you are just defining a model of the numbers. Statements
> > like 1 is really just singleton 0 make me always slightly cringe.
> > :-)
>
> It is probably fine with 1, as there is seemingly no other way to
> define it:-) It is "2" where things become ambiguous: alternative
> definition of "2" is {1}. Also, this construct is no help as far as
> algebraic operations are concerned.

That is a matter of perspective. Some people will say that you first have to define the semantics in set theory and then derive the equalities, others will say that it is the equalities that define the semantics.

But you already make the same mistake. You say things like "define the number 2 as {1}". That is absurd. The number 2 is not a set, it is a number and doesn't contain anything. But somehow most mathematicians get brainwashed during their education and believe that it is quite a logical thing to say.

> > > > RENAME is not really neccesary if you simply assume that your
> > > > tables contain simple tuples like <a,"harry","12-3-52"> without
> > > > column names.
> > >
> > > A newbie question here: how do we join tables without column
> > > names?
> >
> > You don't need the joins because they can be simulated with the
> > (relational) cartesian product followed by a selection and a
> > projection.
>
> True. The question then is about selection. I'm confused about
> notation. Perhaps some example would help.

Suppose you have a relation R(Name,Age,Dept) then the relation will contain tuples like <Name:"Peter", Age:25, Dept:"Treasury">. You can simulate this with normal tuples by assuming that the Name field is the first field, the Age field is the second field and the Dept field is the last field. So then the table will contain the tuple <"Peter", 25, "Treasury">. If there was a selection like SELECT[Age>30](R) then you will have to translate the field references such as 'Age' to the corresponding number, so you get SELECT[#2>30](R).

Quite simple really.

> > But things get, from an algebraic perspective, a little more
> > complicated because the cartesian product does not commute as the
> > join does.
>
> ? (Here I'm illiterate again:-)

The relational cartesian product is defined as follows

  R1 CP R2 = { <m_1,...,m_k, n_1,...,n_l> |<m_1,...,m_k> in R1 and

                                           <n_1,...,n_l> in R2 }

If you want to simulate R1 JOIN R2 then you have to write SEL[#i=#j](R1 CP R2) where #i and #j are the numbers of the fields upon which you want to join. If you join on more than one field than you add another selection. But the problem is that as you can tell by the definition the cartesian product does not commute, i.e., R1 CP R2 <> R2 CP R1.

> > And that also tells how a join can be defined on bags because it
> > will be similar to the cartesian product on bags. So if a tuple
> > occurs n times in a table and is joined with another tuple in
> > another table that appears there m times, then the joined tuple
> > will appear n*m times in the result. And that gives an idea of what
> > will happen if you also assume that your equation has a solution:
> > you will get "complex bags" that may contain a tuple i times where
> > i is the complex number such that i^2 = -1.
>
> Here I feel like I'm tricked up. All that has been done at this point
> is classic algebraic number extension only. It is not extension in
> terms of relational operations.

No, you are wrong, it is. I am just telling you what the interpretation is homomorphic with. Nowhere am I introducing numbers in the algebra.

-- 
  Jan Hidders