# Re: x*x-1=0

Date: 21 Jan 2001 00:18:06 GMT

Message-ID: <94d9ru$i5s$1_at_news.tue.nl>

Vadim Tropashko wrote:

> In article <94amg7$71k$1_at_news.tue.nl>,

*> hidders_at_win.tue.nl (Jan Hidders) wrote:
**> > wrote:
**> > But I suspect what you wanted to talk about was the equation
**> >
**> > x^2 + 1 = 0
**> >
**> > which under the usual interpretation does not have a solution, but
**> > leads to interesting theories if you assume that it does.
**> > Let's see
**> > what happens. First, we try to translate this into rel. algebra:
**> >
**> > (X TIMES ({<1>} UNION {<2>})) UNION ({<3>} TIMES {<3>}) = {}
**>
**> Let me verify here that you are translating linear equation
**> A*x + B = 0
**> , not the quadratic one
**> x*x + 1 = 0
**> (Because we need to be able to solve linear equations first, before
**> moving onto more complex cases;-)
*

Oh dear, you are right, of course. A more correct translation would be:

(X TIMES X) UNION ({<1>} UNION {<1>}) = {}

> > 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.

> 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.

> 2. Column name renaming. Some equations wouldn't have any solutions

*> simply because column name signatures are different, so we need some
**> identities here as well. Here operator RENAME is very confusing. Are
**> we allowed to insert this operator into any part of the equation to
**> "sweeten" the solution (othervise it might bail out on trivial
**> signature mismatch?) BTW, is RENAME a true relational operator that
**> should be added to grand five? I'm personally more happy if it's
**> possible to define some table identities based on table header
**> signatures alone, and drop RENAME altogether.
*

RENAME is not really neccesary if you simply assume that your tables contain simple tuples like <a,"harry","12-3-52"> without column names.

-- Jan HiddersReceived on Sun Jan 21 2001 - 01:18:06 CET