Fixed the number ranges for short and ushort

[bencarlton]

Following the previous version of the chart will result in failed unit tests.

[ErikSchierboom]

This can't be correct, as the 0 to 32_768 range is now unrepresented. There might be something wrong with the tests.

[bencarlton]

In my proposed change 0 to 32_767 range is encapsulated in the the range for the short type which goes from -32_768 to 32_767 and 32_768 is included in the range for the ushort type. If this is not the intention, then there are two tests that are incorrect, ToBuffer_upper_short and ToBuffer_Zero, as the former expects Int16.MaxValue (aka short.MaxValue) to be identified as a short but the table in the exercise identifies it as a ushort and the latter expects 0 to be identified as a short but the table identifies it as a ushort.

[ErikSchierboom]

I think in this case the tests are wrong. To me, the table looks sane. If the tests aren't, we should fix the tests (and the exemplar solution). Do you want to do that?

[bencarlton]

IMHO the proposed revision to the table better fits the pattern for the other signed and unsigned number types, i.e. using int for for ranges of both positive and negative numbers instead of only using it for negative numbers and uint for positive numbers.

However, if you disagree I can submit a pull request correcting the tests and the exemplar solution.

[ErikSchierboom]

IMHO the proposed revision to the table better fits the pattern for the other signed and unsigned number types, i.e. using int for for ranges of both positive and negative numbers instead of only using it for negative numbers and uint for positive numbers.

It does. I just think that the current instructions are fairly confusing. What do you think of exclusively using unsigned types for all the positive integers, and signed types for the negative integers? IMHO that would make a lot more sense.

[bencarlton]

In that case, should it use ulong instead of long for positive numbers greater than uint.MaxValue? That would be introducing a new numeric type that isn't currently covered in the exercise.

[ErikSchierboom]

In that case, should it use ulong instead of long for positive numbers greater than uint.MaxValue? That would be introducing a new numeric type that isn't currently covered in the exercise.

It should. The exercise's introduction mentions ulong, so you're free to use it.

[ErikSchierboom]

Superseded by #1796

Thanks for the effort @bencarlton!