Re: Lucid statement of the MV vs RM position?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 09 May 2006 15:26:49 GMT
Message-ID: <Zw28g.5464$A26.140301@ursa-nb00s0.nbnet.nb.ca>

Jon Heggland wrote:

> Bob Badour wrote:
>

>>Jon Heggland wrote:
>>All of the above is syntax. You point to two different productions in
>>the grammar and claim that only one can be an aggregate. However, this
>>is not true. In both situations above, SUM is an aggregate function.

>
> I don't dispute that; please pay attention. I'm saying that SUMMARIZE is
> not an aggregate operator; in particular, it is not SUM.

That's right. It is just a lexical token in the grammar. The token forms part of a phrase that specifies a projection extended with aggregated operations like addition, union or variance. When applied to an empty relation, the operation specified by the phrase will yield another empty relation of a different type.

One can have other phrases that specify aggregate operations. For instance, one can use SUM token or other aggregate operators without the SUMMARIZE token. When applied to an empty relation, these aggregate operations will yield the identity element for the base operation.

Tutorial D also has a phrase involving the token GROUP. The phrase specifies a combined type conversion and aggregate operation using UNION.

Your whole position seems predicated on GROUP and SUMMARIZE and SUM as tokens in the grammar. As tokens, they are merely symbols with no inherent meaning.

You, yourself, admitted one can define the operation specified by the GROUP phrase as a type conversion and an aggregate using repeated UNION. However else one might define the operation, it must still function as if it were defined as a type conversion and an aggregate using repeated UNION. Otherwise, it would specify a different operation.

SUMMARIZE
> produces a relation; SUM produces a number. Is your point that you
> actually want to use the same name for these two operations? Why?

Don't be absurd.

> All your arguments are just "Yes, it is!".

You have already admitted that it is when you admitted one can define GROUP as a type conversion and iterated UNION. Why you continue to argue that it is something else is beyond me. However else one might define the operation, it must still operate according to the aggregate function definition.

It's like Monty Python's
> Argument Clinic. If you want me to understand your point of view, please
> respond to the concrete questions I ask you in other posts.

I don't care whether you understand my point of view. I am trying to figure out whether you have anything resembling a coherent point to make.

>>As I said previously, you focused on form while Marshall and I focused
>>on function.

>
> As I have said, and as Marshall now agrees, you are talking about some
> GROUP that you have made up yourself, while I talk specifically about
> Tutorial D's GROUP. Trivially, if you define GROUP to be an aggregate
> operator, it *is* an aggregate operator. However, it is not the Tutorial
> D GROUP.
The operation specified by the phrase using the GROUP token in the Tutorial D grammar is an aggregate function. It is in fact a shorthand for a combined type conversion and union aggregate.

>>Do you have a particular objection to the productions D&D chose in the
>>grammar of their tutorial language? If so, which production(s)? How does
>>changing the production(s) improve the language as a language? We might
>>agree with you, and we might not.

>
> Why do you keep bringing up this straw man? I have already said once
> that I don't object to Tutorial D's grammar!

You don't object to the grammar.
But your whole argument is predicated on the grammar itself and specific tokens in isolation.
You admitted one can define the operation specified by the GROUP phrase as a type conversion and aggregate union.

I am concluding that your whole argument is pointless. Received on Tue May 09 2006 - 10:26:49 CDT