Re: x*x-1=0

From: Jan Hidders <>
Date: 22 Jan 2001 09:38:29 GMT
Message-ID: <94gv2l$c38$>

Vadim Tropashko wrote:
> > > > Assuming that this equation is solveable leads to the peculiar
> > > > property that there will be sets that you can add a non-empty set
> > > > to such that the result will be an empty. You might call them
> > > > "negative sets" if you will.
> > >
> > > This is a discovery of negative tables/sets, right? (We are in
> > > the very beginning, therefore, of the classic sequence
> > > negative->rational->complex numbers:-)
> >
> > Sort of. Perhaps you could treat them as some kind of generalized bag
> > where a bag can contain an element -3 times. I doubt if that is
> > really a new idea.
> OK. We assign a weight to each element. Is there a definition of joint
> operation upon such things?

Yes, there is. I will answer that below.  

> > > Still something is not quite right here, and until things would be
> > > cleaned up we cant expect those to be good concepts. Things that
> > > bother me:
> > >
> > > 1. DUM (or '0') - is is a table with no rows an columns only (i), or
> > > any table with empty set of rows (ii)?
> >
> > It is both because both tables are simply the empty set.
> >
> I'm kind of uneasy about set reductionism. This reminds me unfamous
> 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. :-)

But to get back on topic; historically the set interpretation comes before the algebraic equalities. The latter are usually just regarded as a nice bonus that enables you to do query optimization.

> > 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?
> (first rule of relational -- verify everything against joints:-)

You don't need the joins because they can be simulated with the (relational) cartesian product followed by a selection and a projection. But things get, from an algebraic perspective, a little more complicated because the cartesian product does not commute as the join does.

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.

  Jan Hidders
Received on Mon Jan 22 2001 - 10:38:29 CET

Original text of this message