all-your-base: Be explicit about error cases #1000
Conversation
| }, | ||
| { | ||
| "description": "negative digit", | ||
| "property": "rebase", | ||
| "input_base": 2, | ||
| "input_digits": [1, -1, 1, 0, 1, 0], | ||
| "output_base": 10, | ||
| "expected": null | ||
| "expected": {"error": "all digits must satisfy 0 <= d < input base"} |
There was a problem hiding this comment.
pedantic_mode: Is -1 really a digit?
There was a problem hiding this comment.
I see why one would ask this question, and it is true that in all bases allowed in this problem, digits can be considered to be unsigned values.
So thus, I present for academic curiosity https://en.wikipedia.org/wiki/Balanced_ternary, in which there is the possibility of negative digits.
|
Wait a second. I think I can now remove "4. How should invalid input be handled?" from the list of unanswered questions at the top of the file now, right? |
|
So, like this then? If not, Remind me to go back to 7983e19 |
|
I'm becoming more convinced that invalid input handling should not be present in the canonical data. See also: #902 |
|
I wonder if I find it funny that removing all these cases would move to version 1.2.0, whereas keeping them moves to version 2.0.0. Regardless of that, I'll think about whether I want to remove them. |
|
That's more an indication of how screwed up our versioning system is. |
all-your-base 2.0.0 This uses the error object defined in #401 (comment) and thenceforth added to the README's **Test Data Format**. In #280 we made the explicit choice to leave various cases `expected: null` where tracks can make their own decisions (leading zeroes, the representations of zero, whether empty sequence is acceptable as input). However, since `expected: null` is also used for cases where there is always an error (and there is no decision being left to the tracks), it becomes unreasonably hard to tell cases in these two categories apart. To make this easier, all cases in the latter category (always are errors) can canonically be marked as such.
|
What I will say today, and that I can reasonably say there is agreement on, is that if the invalid inputs should be tested, we agree that it is better to expect an The merging of this PR is not to be taken as an acceptance or rejection of the statement "we should remove the invalid inputs from the canonical data" |
all-your-base 2.0.0
This uses the error object defined in
#401 (comment)
and thenceforth added to the README's Test Data Format.
In #280 we made
the explicit choice to leave various cases
expected: nullwhere trackscan make their own decisions (leading zeroes, the representations of
zero, whether empty sequence is acceptable as input).
However, since
expected: nullis also used for cases where there isalways an error (and there is no decision being left to the tracks),
it becomes unreasonably hard to tell cases in these two categories
apart.
To make this easier, all cases in the latter category (always are
errors) can canonically be marked as such.