gold
SELECT tag FROM main.y ORDER BY mass ASC
- mass
- ascending, nulls first
sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11
R-ORD EQUAL ordering-over-numeric-text
questions
What are the tags, lightest first?
the hint the set supplies: the mass refers to main.y.mass
NOT_EQUAL states that these two statements disagree on this data under this rule. It does not state which of them is wrong.
SELECT tag FROM main.y ORDER BY mass ASC
sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11
SELECT t.tag FROM main.y AS t ORDER BY t.mass ASC
sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11
The marked tokens are where the two texts differ. Two statements that differ everywhere can return the same rows, and two that differ in one token can return other rows; the verdict above is read off the results.
from counterexample.json, 0 rows, up to 25 shown per side
| side | tagTEXT |
|---|---|
| no rows |
from counterexample.json, 0 rows, up to 25 shown per side
| side | tagTEXT |
|---|---|
| no rows |
set(second_rows) == set(gold_rows), REAL cells as Python float as sqlite3 returns them, so Python equality holds 1 == 1.0 == True as the benchmark's own scorer does
https://github.com/bird-bench/mini_dev/blob/main/evaluation/evaluation_ex.py
result_eq: equal row counts and equal column counts, each row unordered as a quick rejection, then the two equal as a list when the gold text holds ORDER BY and as a multiset otherwise, under some permutation of the columns; DISTINCT is not stripped and re-executed, and the cells are SQLite's as sqlite3 returns them
ruiqi-zhong/test-suite-sql-eval, exec_eval.py, result_eq, at commit 48cb78ec: https://github.com/ruiqi-zhong/test-suite-sql-eval/blob/48cb78ecf7f610620206283846c76751b18a1326/exec_eval.py
from counterexample.json, 3 rows
| tagTEXT |
|---|
| lead |
| zinc |
| iron |
from counterexample.json, 3 rows
| tagTEXT |
|---|
| lead |
| zinc |
| iron |
A smell is a mechanical reason to read this gold statement again. It is a heuristic: it does not state that the statement is wrong, and a maintainer decides.
this statement orders by a text column holding only numbers, and ordering it as a number gives a different answer, so the gold may be sorting 9.5 above 10
from smells.json, 3 rows
| lead |
| zinc |
| iron |
{
"heuristic": true,
"keys": [
{
"key": "mass",
"column": "main.y.mass",
"declared_type": "TEXT",
"not_applicable": null,
"census": {
"rows": 3,
"nulls": 0,
"empty_strings": 0,
"non_numeric": 0,
"pattern": "^-?[0-9]+(\\.[0-9]+)?$"
},
"every_value_is_numeric": true,
"cast_sql": "SELECT tag FROM main.y ORDER BY CAST(mass AS REAL) ASC",
"verdict": "not_equal",
"gold_result": {
"columns": [
{
"name": "tag",
"declared_type": "TEXT"
}
],
"row_count": 3,
"truncated": false,
"rows_shown": 3,
"rows": [
[
{
"type": "str",
"value": "lead"
}
],
[
{
"type": "str",
"value": "zinc"
}
],
[
{
"type": "str",
"value": "iron"
}
]
],
"result_hash": "sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11"
},
"cast_result": {
"columns": [
{
"name": "tag",
"declared_type": "TEXT"
}
],
"row_count": 3,
"truncated": false,
"rows_shown": 3,
"rows": [
[
{
"type": "str",
"value": "iron"
}
],
[
{
"type": "str",
"value": "lead"
}
],
[
{
"type": "str",
"value": "zinc"
}
]
],
"result_hash": "sha256:1a66ab0ca97f310fad5b8658fedf77579f85c06a8d67bd0fa2ac89d51c5a27c9"
}
}
]
}
this statement cuts its result at a LIMIT that does not decide which rows come back, so a different but equally correct statement can return other rows and score zero
the statement states no LIMIT
{
"heuristic": true,
"reason": "the statement states no LIMIT"
}
rerun over the same rows in another physical order this statement gives another answer, so its result depends on how the rows are stored and not only on the data
{
"heuristic": true,
"rule": "R-ORD",
"baseline_result_hash": "sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11",
"baseline_result": {
"columns": [
{
"name": "tag",
"declared_type": "TEXT"
}
],
"row_count": 3,
"truncated": false,
"rows_shown": 3,
"rows": [
[
{
"type": "str",
"value": "lead"
}
],
[
{
"type": "str",
"value": "zinc"
}
],
[
{
"type": "str",
"value": "iron"
}
]
],
"result_hash": "sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11"
},
"planner_statistics": {},
"shuffle": {
"seed": "1",
"row_limit": 300000,
"tables": [
"main.y"
],
"tables_not_shuffled": [
"main.y"
],
"tables_skipped_for_size": {},
"tables_not_reached_by_a_copy": {
"main.y": "the statement names this table's schema, and a name that states its schema is read from that schema whatever TEMP holds, so the rerun reads this table and not a copy of it"
}
},
"shuffled_copies": {
"run": false,
"reason": "the shuffle reached no table this statement reads, so a rerun would read the same rows in the same order"
},
"plan_variant": {
"run": false,
"reason": "the plan variant was not asked for"
}
}
this statement returns the same whole row more than once and never says DISTINCT, so a statement answering the same question once per row disagrees on multiplicity alone
{
"heuristic": true,
"rows": 3,
"distinct_rows": 3,
"repeated_rows": 0,
"largest_repeat": 1,
"result_bounded": false,
"distinct_stated": false,
"set_operation": false
}
SELECT tag FROM main.y ORDER BY mass ASC
result_hash sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11 recomputed from this JSON: match
record_hash sha256:6ac6e29520c984a8082ee73f4c7189fdbe1f81d2de71a16df31d715451bb1b9e recomputed from this JSON: match
from evidence-gold.json, 3 rows
| tagTEXT |
|---|
| lead |
| zinc |
| iron |
SELECT t.tag FROM main.y AS t ORDER BY t.mass ASC
result_hash sha256:a62cb2d57d7399658fa87921cd0ba954a94549f8d58516c676e0948391b3ec11 recomputed from this JSON: match
record_hash sha256:451cb4c56d38aeb7029792a4615c998b5693b0cec83f84d977b58a0e15736f21 recomputed from this JSON: match
from evidence-second.json, 3 rows
| tagTEXT |
|---|
| lead |
| zinc |
| iron |
re-run this statement read-only against SQLite 3.53.1 | file=/tmp/attestql-site-sandbox/demo/fixture.sqlite | size=69632 under the session settings and over the data this record's fixture digest names, and compare the two results under R-ORD
re-run this statement read-only against SQLite 3.53.1 | file=/tmp/attestql-site-sandbox/demo/fixture.sqlite | size=69632 under the session settings and over the data this record's fixture digest names, and compare the two results under R-ORD