Re: Lucid statement of the MV vs RM position?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 08 May 2006 22:04:24 GMT
Message-ID: <IfP7g.5181$A26.131966_at_ursa-nb00s0.nbnet.nb.ca>
>
> I'm not quite sure I understand your argument here; please ignore if I'm
> setting up a straw man here. I think the distinction between SUMMARIZE
> ... ADD (SUM(...) AS ...) and SUM(...) is crucial for at least two reasons:
>
> 1. A SUMMARIZE can apply more than one aggregate operator. If you use
> the name SUM for a SUMMARIZE that applies iterated addition on one
> attribute, and the name GROUP for a SUMMARIZE that applies iterated
> union on one attribute, what do you call a SUMMARIZE that applies both
> addition and union in one go? Or would you disallow such an operation,
> forcing it to be implemented as two separate aggregate operator
> invocations, followed by a join? Much pain for no gain, if you ask me.
>
> 2. If you define aggregate operators this way, you have to repeat the
> definition of the "grouping procedure" for each one. Using SUMMARIZE, it
> is factored out, and all you need to add a new aggregate operator is to
> specify the operator and the identity.
>
> Furthermore, Tutorial D's aggregate operators can also be used as
> expressions directly, i.e. not only within the context of a SUMMARIZE.
> For example, SUM(R,A) is an expression evaluating to the sum of the A
> attribute in relation R. If SUMMARIZE ... ADD (SUM(...) AS ...) is
> called "the aggregate operator SUM", what should we call SUM(R,A)? They
> are obviously not the same.
Date: Mon, 08 May 2006 22:04:24 GMT
Message-ID: <IfP7g.5181$A26.131966_at_ursa-nb00s0.nbnet.nb.ca>
Jon Heggland wrote:
>>Jon Heggland wrote: >> >>>I focus on the significant difference between >>> >>>1. An aggregate operator >>>2. The invocation of an aggregate operator within a SUMMARIZE operator >>> >>>You don't get from relation (1) to relation (2) in my post to Marshall >>>just by using SUM. You have to use SUMMARIZE as well. >> >>I agree, however I consider this point so obvious as to be not >>worth mentioning. No one bothers to distinguish carefully >>between, say, a function literal and an application of that >>function in speech. It's just quite clear from context.
>
> I'm not quite sure I understand your argument here; please ignore if I'm
> setting up a straw man here. I think the distinction between SUMMARIZE
> ... ADD (SUM(...) AS ...) and SUM(...) is crucial for at least two reasons:
>
> 1. A SUMMARIZE can apply more than one aggregate operator. If you use
> the name SUM for a SUMMARIZE that applies iterated addition on one
> attribute, and the name GROUP for a SUMMARIZE that applies iterated
> union on one attribute, what do you call a SUMMARIZE that applies both
> addition and union in one go? Or would you disallow such an operation,
> forcing it to be implemented as two separate aggregate operator
> invocations, followed by a join? Much pain for no gain, if you ask me.
>
> 2. If you define aggregate operators this way, you have to repeat the
> definition of the "grouping procedure" for each one. Using SUMMARIZE, it
> is factored out, and all you need to add a new aggregate operator is to
> specify the operator and the identity.
>
> Furthermore, Tutorial D's aggregate operators can also be used as
> expressions directly, i.e. not only within the context of a SUMMARIZE.
> For example, SUM(R,A) is an expression evaluating to the sum of the A
> attribute in relation R. If SUMMARIZE ... ADD (SUM(...) AS ...) is
> called "the aggregate operator SUM", what should we call SUM(R,A)? They
> are obviously not the same.
As I said previously, you focused on form while Marshall and I focused on function.
Are we talking about multiple productions in the grammar? Sure.
Does that make GROUP any less an aggregate defined on UNION? No.
However, I am not sure how you are going to establish a theory based argument for a minor matter of language design and syntax.
[snip] Received on Tue May 09 2006 - 00:04:24 CEST