Побитовое НЕ

[Decode]

Число 10 в двоичной системе — 00000000000000000000000000001010.
Если к нему применить ~10, должно быть — 11111111111111111111111111110101.

Почему ~10..toString(2) дает 1011 на конце?

[EmperioAf]

https://learn.javascript.ru/bitwise-...�овое-не

Из-за внутреннего представления отрицательных чисел получается так, что ~n == -(n+1).

[Malleys]

Для того, чтобы перевести число в двоичную систему, надо представить его в виде суммы степеней двойки и выписать коэффициенты. Например 10 = 1 * 2^3 + 0 * 2^2 + 1 * 2^1 + 0 * 2^0. Поэтому в двоичной системе 10 записывается так: 1010.

В памяти компьютера целые числа могут занимать например 32 бита, т. е. 4 байта. Внутреннее предствление числа 10 в таком случае будет: 00000000 00000000 00000000 00001010.

Число ~10 будет представлено как 11111111 11111111 11111111 11110101. Ему соответствует десятичное число -11, которое в двоичной системе записывется так: -1011.

В последнем случае видно, что запись отрицательного числа в памяти зависит от отвеленного ему места в памяти. Т. е. ~10 в случае отведённого ему места в 8 бит, выглядит как 11110101 и соответствует десятичному числу 245, а не -11.

(~10).toString(2) == '-1011' // Переводит ~10 = -11 в двоичную систему счисления

[Rise]

Malleys,

В последнем случае видно, что запись отрицательного числа в памяти зависит от отвеленного ему места в памяти. Т. е. ~10 в случае отведённого ему места в 8 бит, выглядит как 11110101 и соответствует десятичному числу 245, а не -11.

Почему тогда '-1011' куда делись 245 и 11110101 ?

[Rise]

Decode, оказывается (-Number).toString(2) работает с Number как с положительным числом а потом прибавляет '-':

alert( (-11).toString(2) );
alert( (11).toString(2) );

Как и parseInt('Number', 2) видит Number только как положительное двоичное число а потом прибавляет '-':

alert( parseInt('-1011', 2) );
alert( parseInt('1011', 2) );

Для представления отрицательного двоичного числа нашел такое:

alert( (-11 >>> 0).toString(2) );
alert( parseInt('11111111111111111111111111110101', 2) >> 0 );

Теперь всё как надо:

alert( (~10 >>> 0).toString(2) );

Таким образом однозначно могут быть представлены целые числа от 0 до 2147483647 и от -2147483648 до -1, с оговоркой, что они 32-х битовые.

[Malleys]

Malleys, почему тогда '-1011' куда делись 245 и 11110101 ?

Никуда. Двоичное 11110101 это десятичное 245, но если воспринимать его как 8 битовое число, то оно означает десятичное -11.
Если -11 перевести в двоичную систему, получим -1011.

alert( (-11 >>> 0).toString(2) );
alert( parseInt('11111111111111111111111111110101', 2) >> 0 );

Предложенный Вами способ приводит к неоднозначности:

alert((-11 >>> 0).toString(2)          == '11111111111111111111111111110101');
alert((-4294967307 >>> 0).toString(2)  == '11111111111111111111111111110101'); // Перевод разных чисел соответствует одному и тому же числу...

Зачем вы используете для перевода чисел в двоичную систему побитовый сдвиг вправо, если он при этом конвертирует числа в 32-х битовые???
По сути вы находите остаток от деления на 2^32.

alert((-30064771072 >>> 0).toString(2)); // переводит неверно
alert((-30064771072).toString(2)); // переводит верно

1.25 = 1 * 2^0 + 0 * 2^(-1) + 1 * 2^(-2) = двоичное 1.01

alert((1.25 >>> 0).toString(2)); // переводит неверно
alert((1.25).toString(2)); // переводит верно

Почему ~10..toString(2) дает -1011?
Потому что -11 представлено в виде суммы степеней двойки и выписаны коэффициенты.
Почему ~10 даёт -11, а не двоичное 11111111111111111111111111110101?
Потому что операнды всех битовых операций конвертируются в 32-х битовые целые со знаком представленные в дополнительном бите.
Таким образом однозначно могут быть представлены целые числа от 0 до 2147483647 и от -2147483648 до -1, с оговоркой, что они 32-х битовые.

[Rise]

Malleys, сложная тема, мозг кипит от этих битов

[Decode]

Разобрался

https://ru.wikipedia.org/wiki/%D0%94...81%D0%BB%D0%B0)