Re: GROUP BY

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sat, 19 May 2007 20:37:28 -0400
Message-ID: <dLM3i.3696$4Y.394_at_newssvr19.news.prodigy.net>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:464f4dd6$0$4052$9a566e8b_at_news.aliant.net...
> Marshall wrote:
>
>> On May 19, 7:38 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>>
>>>"Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>>
>>>
>>>>So: what *about* that extended extend?
>>>
>>>>Extend is a particular form of join, yes? So perhaps we
>>>>ought to apply generators with join?
>>>
>>>>I note that there is an issue with regards to the uniqueness
>>>>of values produced by a generator. It's not clear to me if
>>>>that ought to be required or not. If it's required, it's not clear
>>>>to me if it's enforceable, since I don't see how to prove uniqueness.
>>>
>>>>If the outputs of the generator aren't unique, then we have
>>>>a function from a tuple to a bag, which also matches the
>>>>fact that aggregate functions are functions from a bag to
>>>>a tuple.
>>>
>>>I don't agree with this. An aggregate function iterates over a relation,
>>>taking a projection of each tuple to find the values required to
>>>calculate
>>>the result.
>>
>> Well, that's not really incompatible with what I wrote. You've given
>> an operational description; mine is more ... mathematical? abstract?
>
> How about "Correct" ?
>
> Project a tuple? I suppose one can project a point in an n-space into
> another space. But is that really how one finds the values required to
> calculate anything? After one projects, most of the values required for
> the calculation are gone.
>
>
>> Yours is maybe a bit narrow, though, because by being so specific
>> about the algorithm to implement aggregation, you've eliminated
>> the possibility for parallelization.
>
> You are making more sense out of what he wrote than is even there. I
> suggest you stop trying so hard to make sense out of nonsense.
>
>
>>>While it is convenient to visualize the collection of values
>>>for an attribute in a relation as a bag, it should not be ignored that
>>>any
>>>particular combination of values in that bag depends solely on the
>>>existence
>>>of a particular *set* of tuples.
>>
>> Um, I don't see how. Anyway, we can certainly consider sum() in
>> the abstract. It is a function taking a bag of numbers to a single
>> number.
>> In some languages it is considered to take a list, but that too is
>> overspecifying, since order is not significant.
>
> Whether order is significant depends on the base operation. Addition is
> associative and commutative, but not all operations are.
>
> I reiterate: You are trying too hard to make sense out of nonsense.
>
> [snip]
Received on Sun May 20 2007 - 02:37:28 CEST

Original text of this message