W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: more aggregate tests

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 14 Sep 2010 09:26:53 +0100
Message-ID: <4C8F31CD.8090108@epimorphics.com>
To: Gregory Williams <greg@evilfunhouse.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
Greg,

I tried your tests : they look OK but require value-based result set 
testing which ARQ does not (currently) provide so it's an optical 
checking for now.

The new tests weren't in the entries list and so I've committed changes 
to the manifest for this to CVS.

I have also gone through the exiting tests - outstanding technical 
discussion needs concluding.

	Andy

On 14/09/10 01:59, Gregory Williams wrote:
> I've committed several aggregate tests to CVS for AVG, MIN, MAX, SUM and SAMPLE [1]. I've guessed in a few places what the correct results should be (especially for SUM and AVG) based on my understanding of the current spec text, the numeric type promotion rules and whether a system produces canonical lexical forms. My system passes all of the new tests.
>
> I've also updated the default prefix URI in the aggregate, project expression, and property path manifest files so that all tests consistently use namespaces within the /2009/sparql URI space.
>
> thanks,
> .greg
>
> [1] http://www.w3.org/2009/sparql/docs/tests/data-sparql11/aggregates/

(tests from before - still unresolved issues):
----
:agg08: COUNT 8:

SELECT ((?O1 + ?O2) AS ?O12) (COUNT(?O1) AS ?C)
WHERE { ?S :p ?O1; :q ?O2 } GROUP BY (?O1 + ?O2)
ORDER BY ?O12

ARQ does not support the reuse of unnamed expression (it could for some 
reasonably practical definition of expression equality based on syntax). 
This is an outstanding point of discussion which seems to have died out.

http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0280.html

I thought we concluded that expression equality was not going to be 
required. The idea of allowing naming in GROUP BY works and is my 
preferred option because it works with HAVING:

SELECT ?O12 (COUNT(?O1) AS ?C)
WHERE { ?S :p ?O1; :q ?O2 }
GROUP BY (?O1 + ?O2 AS ?O12)
HAVING (?O12 > 56)

This relates to the translation of syntax to algebra.

----
:agg09: COUNT 9,10,11,12

Projection an ungrouped variable.
Projection part of a group by expression.

Should be an error; in ARQ currently, is an unbound variable.

-----------------
Greg's new tests:

Failure: Test 13 :: SUM with GROUP BY
Got: 5 --------------------------------
------------------------------------
| s         | sum                  |
====================================
| :ints     | 6                    |
| :mixed2   | 2.4000000000000004e0 |
| :mixed1   | 3.2                  |
| :doubles  | 32100.0e0            |
| :decimals | 6.7                  |
------------------------------------
Expected: 5 -----------------------------
----------------------
| sum    | s         |
======================
| 2.4E0  | :mixed2   |
| 3.2    | :mixed1   |
| 3.21E4 | :doubles  |
| 6.7    | :decimals |
| 6      | :ints     |
----------------------

"E" or "e" are legal which makes comparison by lexical form tricky.
Currently, I check results sets by encoding as graphs and performing 
graph isomorphism (a built-in test in Jena) which deals with the bNodes 
nicely but the test is done without full value-based testing.

I can added result set testing by value with bnode isomorphism.  Small 
matter of programming.

Tests

:agg-avg-01
:agg-avg-02
:agg-min-01
:agg-min-02
:agg-max-01
:agg-max-02
:agg-sum-01
:agg-sum-02
:agg-sample-01

are not in the list of entries to run.  Fixed and committed to CVS.

Failure: Test 14 :: AVG
Got: 1 --------------------------------
------------------------------
| avg                        |
==============================
| 2.220000000000000000000000 |
------------------------------
Expected: 1 -----------------------------
--------
| avg  |
========
| 2.22 |
--------

Result testing isn't value based, and once arithmetic is done to 
decimals, their scale becomes 24 (18 is the minimum required by F&O), 
and Java BigDecimal prints the trailing zeros to indicate this.

=======================================
Failure: Test 15 :: AVG with GROUP BY
Got: 3 --------------------------------
----------------------------------------
| s       | avg                        |
========================================
| :ints   | 2.000000000000000000000000 |
| :mixed2 | 1.2000000000000002e0       |
| :mixed1 | 1.600000000000000000000000 |
----------------------------------------
Expected: 3 -----------------------------
-------------------
| avg   | s       |
===================
| 2     | :ints   |
| 1.2E0 | :mixed2 |
| 1.6   | :mixed1 |
-------------------

More of the same. Precision issues + e/E issues.
Received on Tuesday, 14 September 2010 08:27:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT