Re: Aggregation Set Functions

Sounds very reasonable to me as well (I also remember that the err-count was more something speculative back when we introduced it).
It seems to override the following resolution though 
  http://www.w3.org/2009/sparql/meeting/2010-03-26#resolution_2

Do we need a new resolution to override it? Something like:
 
 PROPOSED: Drop error counts in the semantics definition of aggregate functions, overriding http://www.w3.org/2009/sparql/meeting/2010-03-26#resolution_2 with the insight that it is not needed/special aggregates could define/implement error counts.

?

Axel

On 11 Feb 2011, at 15:16, Matthew Perry wrote:

> Ok. That works for me.
> 
> - Matt
> 
> On 2/11/2011 10:09 AM, Steve Harris wrote:
> > It does as written, but that's an unintended consequence, the def'n of Count() will need to be change to not count error values.
> >
> > - Steve
> >
> > On 2011-02-11, at 14:00, Matthew Perry wrote:
> >
> >> Hi Steve,
> >>
> >> Lets say M = (1, 2, 3, "a", "b")
> >>
> >> Does this change COUNT(xsd:int(?x)) from 3 to 5?
> >>
> >> - Matt
> >>
> >> On 2/11/2011 7:03 AM, Steve Harris wrote:
> >>> I've spoken with Andy on IRC, and he also agrees that it's probably better without it, so the current draft of rq25 doesn't have the error count argument.
> >>>
> >>> Following some discussion on IRC last night, I've also clarified the return types of the set functions.
> >>>
> >>> - Steve
> >>>
> >>> On 2011-02-11, at 10:55, Steve Harris wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Currently the Set Functions in Aggregates (ie. the underlying functions) are defined like:
> >>>>
> >>>> Func(M, errors, scalars)
> >>>>
> >>>> where M a multiset of the values from the group, e.g. if you have SUM(?x) and ?x is 1,2,3 in the group, then M = (1,2,3). But M is defined used ListEvalE(), so all the results which are errors are removed from the multiset.
> >>>>
> >>>> errors is a count of the errors (which where removed from M).
> >>>>
> >>>> I think it would be much simpler if instead M included the errors, and the error count argument was dropped, then it would be:
> >>>>
> >>>>    M = ListEval(exprlist, range(g))
> >>>>
> >>>>    func(M, scalarvals), for non-DISTINCT
> >>>>    func(Distinct(M), scalarvals), for DISTINCT
> >>>>
> >>>> Dave B also complained about the error count argument saying it was redundant in his comment.
> >>>>
> >>>> I don't quite remember why it was included? I think Andy S might have suggested it, something about future extensibility? But I don't see what function it performs.
> >>>>
> >>>> So, my question is, can anyone think of a good reason to keep it?
> >>>>
> >>>> - Steve
> >>>>
> >>>> --
> >>>> Steve Harris, CTO, Garlik Limited
> >>>> 1-3 Halford Road, Richmond, TW10 6AW, UK
> >>>> +44 20 8439 8203  http://www.garlik.com/
> >>>> Registered in England and Wales 535 7233 VAT # 849 0517 11
> >>>> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
> >>>>
> >>>>
> 
> 
>

Received on Monday, 14 February 2011 12:05:59 UTC