Reword 45 and -19 being indistinguishable modulo 64, '101101'

Author: jb2170

peps/pep-0786.rst

@@ -118,7 +118,7 @@ Conversely it should be clear that one can losslessly truncate a signed number's
     -19 (8-bit)  11101101
     -19 (7-bit)   1101101
 
-If one were to truncate another digit off of these examples, then both would end up as ``101101``, 45 indistinguishable from -19 when using only 6 binary digits because they are both the same modulo ``2 ** 6 = 64``. Therefore to losslessly and unambiguously represent a signed integer ``x`` as a binary string which is rendered to the end user, we have a de facto 'minimal width' representation convention, using ``n`` digits, where ``n`` is the smallest integer such that ``x`` is in ``range(-2 ** (n-1), 2 ** (n-1))``.
+If one were to truncate another digit off of these examples, then both would end up as ``101101``, 45 being indistinguishable from -19 when using only 6 binary digits because they are both the same modulo ``2 ** 6 = 64``. Therefore to losslessly and unambiguously represent a signed integer ``x`` as a binary string which is rendered to the end user, we have a de facto 'minimal width' representation convention, using ``n`` digits, where ``n`` is the smallest integer such that ``x`` is in ``range(-2 ** (n-1), 2 ** (n-1))``.
 
 For rendering octal and hexadecimal strings one has to extend the definition of the 'minimal width' representation convention to be sufficiently unambiguous. 383's minimal width binary string is ``0101111111``, and -129's is ``101111111``, a suffix of the former's. A naive, incorrect, implementation of hexadecimal string formatting would render both as ``'0x17f'`` by *padding* both binary representations to ``000101111111``. The method was correct to desire a number of binary digits (12) that is divisible by the number of bits in the base (4 bits in base 16) so that the binary representation can be segmented up into (hex) digits, but it was incorrect in *padding*; the method should have instead *extended* as we have observed previously, 383 extended to ``000101111111``, and -129 extended to ``111101111111``, whence 383 is rendered as ``'0x17f'`` and -129 as ``0xf7f``.