Re: Operationalize orthogonality

From: Marshall <marshall.spight_at_gmail.com>
Date: 5 Jun 2006 07:38:58 -0700
Message-ID: <1149518338.396377.118460_at_i39g2000cwa.googlegroups.com>


Tony D wrote:
> Hmmm ... I tried answering this before, and it appears to have gone
> down the memory tube. [...]

I *hate* when that happens.

> Marshall wrote:
> > Tony D wrote:
> >
> > I'm not sure what you're referring to. Maybe it's that the equality
> > function might be expensive? If so, that offers no theoretical
> > impediment. Join is guaranteed to complete and return a value
> > (assuming it is well-typed;) it is *not* guaranteed to be fast.
> >
>
> Cost isn't an issue for us here. Efficiency is an implementation issue.
> Think name spaces, scope and what can appear on either side of the
> comparison operator.

I think I see. You're talking about the naming issues? If we want to sort a relation on attribute a, we have to repeatedly compare two "a" values which will have the same name, is that it?

I admit I haven't put any attention into theoretical concerns about sorting. It could be expressed as an aggregate function, couldn't it? After all, when one sorts, the result isn't a relation, because a relation has no order.

Off the top of my head, the result is a list if the sort is total, and ... a list of sets if it's a partial order? I mean, it's a lattice, really, but couldn't you represent a lattice as a list of sets? How *would* you represent a lattice.

Just speculating here; happy to hear better ideas.

Marshall Received on Mon Jun 05 2006 - 16:38:58 CEST

Original text of this message