Date: Tue, 12 Apr 2022 19:16:24 +0200
In Expressions, Integral conversions, the same formula is given for conversion to unsigned and to signed:
> Otherwise, the result is the unique value of the destination type
> that is congruent to the source integer modulo $2^N$,
> where $N$ is the width of the destination type.
I believe that this cannot be right: it would imply that signed integers of the same width have the same range of positive numbers as unsigned integers, so for signed integrals, a power N-1 should be used, to account for the reduced positive range due to the "sign bit" (if you can use that term for two-s complement).
Moreover, the use of modulo to limit the number range both on the negative and the positive side would fail for most modulo definitions because the negative range of two-s complement numbers is larger than the positive range. For example, use of modulo fails on the negative side if modulo would be defined like the remainder (%) operator from C++.
Even though the intention is that the result is the result bit representation of the N least-significant-bits of the source representation, this seems to not fit well with the language of the rest of the standard, which tries to abstract the internal representation. I assume that this motivated the change that introduced this problem (git commit "P1236R1 Alternative Wording for P0907R4 Signed Integers are Two's Complement", 3b7ee0048a8aeaac1a3a9d5193be77aa2778c969).
In most cases, the language uses the "modulo $2^N$" formulation, but this operation seems poorly defined when applied to negative numbers. I tried to reformulate the conversion so, that modulo is only applied to positive numbers, but this to get very wordy. Also, I am unsure if the case of conversion from signed to unsigned and vice versa should also be considered, because these are generally also well-defined once one assumes two-s complement coding for signed integrals.
Anyway, before I go on, could you please confirm that, at least in this case, the confusion is not in my mind?
> Otherwise, the result is the unique value of the destination type
> that is congruent to the source integer modulo $2^N$,
> where $N$ is the width of the destination type.
I believe that this cannot be right: it would imply that signed integers of the same width have the same range of positive numbers as unsigned integers, so for signed integrals, a power N-1 should be used, to account for the reduced positive range due to the "sign bit" (if you can use that term for two-s complement).
Moreover, the use of modulo to limit the number range both on the negative and the positive side would fail for most modulo definitions because the negative range of two-s complement numbers is larger than the positive range. For example, use of modulo fails on the negative side if modulo would be defined like the remainder (%) operator from C++.
Even though the intention is that the result is the result bit representation of the N least-significant-bits of the source representation, this seems to not fit well with the language of the rest of the standard, which tries to abstract the internal representation. I assume that this motivated the change that introduced this problem (git commit "P1236R1 Alternative Wording for P0907R4 Signed Integers are Two's Complement", 3b7ee0048a8aeaac1a3a9d5193be77aa2778c969).
In most cases, the language uses the "modulo $2^N$" formulation, but this operation seems poorly defined when applied to negative numbers. I tried to reformulate the conversion so, that modulo is only applied to positive numbers, but this to get very wordy. Also, I am unsure if the case of conversion from signed to unsigned and vice versa should also be considered, because these are generally also well-defined once one assumes two-s complement coding for signed integrals.
Anyway, before I go on, could you please confirm that, at least in this case, the confusion is not in my mind?
Received on 2022-04-12 17:16:29