Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzy requirement : AVG #9

Closed
BorderCloud opened this issue Feb 24, 2015 · 4 comments
Closed

Fuzzy requirement : AVG #9

BorderCloud opened this issue Feb 24, 2015 · 4 comments

Comments

@BorderCloud
Copy link
Owner

As Sebastian Schaffert said:

AVG should accept all numeric return types
The tests currently require that the result of AVG always is the same type as the input arguments. However, the SPARQL 1.1 specification defines AVG as to return any numeric value. The tests should therefore only check if the return type is numeric.
This also makes sense when you take e.g. the example of the average of the integers 1 and 2 - which is the double or decimal value 1.5.

For me the requirements are fuzzy because it's not possible to make unit tests for all the cases. The AVG's test are logic but it is necessary to add more unit tests for the functions like AVG and so clarify the requirements.

What did you think ?

@VladimirAlexiev
Copy link

As far as I can see, https://www.w3.org/TR/sparql11-query/#defn_aggAvg doesn't specify the output datatype.
So the best would be if you can compare the expected and result numerically, but I guess the result comparator doesn't have that flexibility.

@BorderCloud
Copy link
Owner Author

A unit test don't need to flexible... It's the specification need to be clear.

@VladimirAlexiev
Copy link

You can't change the spec. "1.5"^^xsd:decimal and "1.5"^^xsd:float are equivalent (compatible) results of avg() so your comparator must accept them.

rdf-canonize happens to make them the same through conversion to JSON-native values, see digitalbazaar/rdf-canonize#10.

@VladimirAlexiev
Copy link

it's not possible to make unit tests for all the cases.

It is certainly possible to compare values in a more flexible way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants