Есть несколько причин для этого ..
Во-первых, умножение и деление на самом деле быстрее в некоторых обстоятельствах
когда мы используем сдвиг влево, сдвиг вправо ...
т.е. число 1 в двоичном виде - 00000001
Сдвиньте его влево, чтобы оно стало 00000010, и теперь оно 2 .. т.е. 1 х 2
Сдвиньте его дважды, чтобы умножить / разделить на 4, 3 раза на 8, 4 раза на 16 и т. Д. *
Он используется не слишком часто, но в таких случаях, как порт физического движка из C / C ++, обработка огромных объемов данных или некоторые из трехмерных движков, мы увидим сдвиги как остаток исходного кода или просто для скорости.
(Вы могли бы видеть это и в некоторых мобильных java-играх J2ME, например, где единицы с плавающей запятой недоступны, то есть сдвиг значения влево на 10 бит, так что оставшиеся 10 битов действуют как своего рода десятичная точка ... затем сдвиньте его вернуться к действительному значению при рисовании на экране, за счет общего возможного размера)
Другое упомянутое использование для быстрого Math.floor (); - но с ключевым отличием.
Несколько месяцев назад я провел несколько тестов, работая с Box2D, и обнаружил, что это в сотни раз быстрее - странно, поскольку я предполагаю, что оба преобразования обрабатываются изначально.
При округлении отрицательных чисел,
Math.floor (-7,6) = -8
а также
(-7,6 << 0) = -7 </p>
т.е. << 0 на число (float) будет округлять в направлении 0. </p>