Re: Operationalize orthogonality
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