Re: GROUP BY

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news: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.
>>

From TTM:

<tuple project>

    ::= <tuple exp>

                 {  [ ALL BUT ] <attribute ref commalist> }

Bob, I think you may need to brush up a little. Toe jams really make your breath stink!

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

Either state your objection coherently, or just shut up!

>>
>>>>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:57:39 CEST