all-your-base: Be decisive about zeroes #1001
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
all-your-base 2.0.0 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). There are four affected cases. #473 results in a discussion that some post-processing is necessary, based on the decisions that a given track makes. One might even imagine that each individual generator may have to reimplement base translation to arrive at the proper answers for each case. To ease the process of translation, instead we make some canonical choices, explicitly show what the choices are, and offer that tracks may make a different choice if desired. A previous proposal did not receive support: #468 However, this proposal differs because it does change the comments at the top of the file. Closes #1002 by mutual exclusion
petertseng
commented
Nov 10, 2017
| "It's up to each track do decide:", | ||
| "This canonical data makes the following choices:", | ||
| "1. Zero is always represented in outputs as [0] instead of [].", | ||
| "2. In no other instances are leading zeroes present in any outputs.", |
There was a problem hiding this comment.
this is not really a choice that I expect there to be controversy on, so I guess it is just here to be a foil to choice 1.
petertseng
commented
Nov 10, 2017
| "This canonical data makes the following choices:", | ||
| "1. Zero is always represented in outputs as [0] instead of [].", | ||
| "2. In no other instances are leading zeroes present in any outputs.", | ||
| "3. Leading zeroes are accepted in inputs.", |
There was a problem hiding this comment.
it should be relatively obvious that the opposite choice is "rejected", so a clause, "rather than being rejected" was not added.
Insti
approved these changes
Nov 10, 2017
ferhatelmas
approved these changes
Nov 10, 2017
|
I think I'll make this 1.2.0 since this commit doesn't introduce any new types that were not already present in this file. That way I can merge this then #1000 and end with version 2.0.0 rather than 3.0.0 or 2.1.0 or something. Not that there's any benefit to being minimal with version changes. |
That means we temporarily restore the "invalids are null" text, only to remove it in #1000
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
all-your-base 2.0.0
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).
There are four affected cases.
#473 results in
a discussion that some post-processing is necessary, based on the
decisions that a given track makes. One might even imagine that each
individual generator may have to reimplement base translation to arrive
at the proper answers for each case.
To ease the process of translation, instead we make some canonical
choices, explicitly show what the choices are, and offer that tracks may
make a different choice if desired.
A previous proposal did not receive support:
#468
However, this proposal differs because it does change the comments at
the top of the file.
Closes #1002 by mutual exclusion