In some cases, Double values formatted with the «R» standard numeric format string do not successfully round-trip if compiled using the /platform:x64 or /platform:anycpu switches and run on 64-bit systems. To work around this problem, you can format Double values by using the «G17» standard numeric format string. The following example uses the «R» format string with a Double value that does not round-trip successfully, and also uses the «G17» format string to successfully round-trip the original value.
Попробуйте собрать этот-же код под x86. ;)
Разница не в точности double, а в точности выполнения «внутренних»/«промежуточных» арифметических операций внутри процессора. Это поведение платформо-зависимо: на x86 используется x87 FPU, на x64 — SSE2.
isNaN — это не проверка на то, что аргумент не является числом. isNaN — это проверка на то, что аргумент является «нечислом». NaN — это особое зарезервированное значение числа с плавающей точкой, определённое в стандарте (так же как и, например Infinity), а не просто «всё что угодно кроме числа».
То есть, как это ни странно NaN — формально как раз число.
typeof(NaN); // "number"
Грубо говоря, функция isNaN(value) эквивалентна (value === NaN), если бы не одно но: NaN неравен сам себе, поэтому-то и запилили эту функцию.
Ничто ни во что не превращается! Просто у Number (aka IEEE 754 double-precision aka binary64) хватает точности без ошибок представлять любое целое число вплоть до Number.MAX_SAFE_INTEGER (9007199254740991 = 2^53 - 1). В С# поведение double идентично.
Я, честно говоря, думал, что это настолько очевидно, что постеснялся заворачивать камент в тег sarcasm, но видимо надо было. Я думаю, все, кто пользовался typescript, или даже просто транспайлером а-ля babel и webpack — прекрасно понимают откуда берутся фичи.
Я россиянин. Я не пишу про «сраную рашку», но, должен признать, некоторая доля злорадства всё-же имеется. Причина тому — Рогозин и Ко. Я не знаю как назвать это чувство, что-то вроде испанского стыда за начальство. Если начальник кретин — ты начинаешь его ненавидеть (причем сильно больше, чем если бы кретин был бы чужим начальником). Если ты в корне не согласен с высказываниями и действиями, которые делаются в том числе и от твоего имени (когда Рогозин говорит ртом, то он выражает позицию не свою лично, а, как бы, говорит от лица России, в том числе и от моего), то без возможности на это как-то действенно повлиять — со временем это чувство вырождается в злорадство, к сожалению.
Обычная человеческая слабость. Бесполезная, не конструктивная, но, мне лично, понятная.
По сути сказанного со всем согласен, но одно замечание: вспышку 10 мсек человек очень даже заметит, вспомните фотоаппарат. Можно и за пикосекунду столько фотонов в глаз напихать, что ослепит.
В декабре 2019 ради эксперимента поднимал 32 инстанса в Лондонском ДЦ DigitalOcean. Из России недоступены оказались все 32!
В случае с ДЦ во Франкфурте наоборот — из 32 IP всё оказались доступны.
Что касается коллизий — в статье даже не упомянули о самом интересном: что будет, если шаг (скорость * dt) будет больше чем сумма радиусов сталкивающихся объектов.
Вы уверены, что понимаете что переводите в этом месте?
for (let [i, o1] of o.entries()) { // для каждой пары объектов
for (let [i, o2] of o.entries()) {
if (i < j) { // делаем одно и тоже дважды для каждой пары
...
Но всё это совершенно не оправдано в нашем случае. И не красиво.
А вот функция clampNumber() — вполне self-explaining code. Ведь вам сам API как бы говорит: «программист, позаботься о том, чтобы громкость была в интервале от 0 до 1, иначе я ломаюсь».
Ага, кажется понял о чем вы. «Странные» некруглые значения громкости — это всего лишь артефакт того, что значение храниться во float.
В нормальных (ирония) языках вроде C, где есть отдельно целочисленные и плавающие типы, такое поведение — обычное дело. Там никого не удивишь, что 0.0001 + 0.0002 != 0.0003. А в javascript число представлено одним универсальным типом IEEE 754 binary64. Что позволяет однозначно закодировать (в том числе и) диапазон целых чисел от Number.MIN_SAFE_INTEGER до Number.MAX_SAFE_INTEGER и как будто бы ожидать от number поведение, свойственное для integer в других языках: 123 + 456 == 579 строго. И это ослабляет бдительность. Ведь по-прежнему 0.1 + 0.2 == 0.30000000000000004
А в нашем случае вообще происходит итеративное сложение, которое за каждую операцию накапливает в себе ошибку. Так что это поведение абсолютно нормально. Чтобы видеть красивые ровные проценты в UI — отображаемое значение необходимо округлить. Это стандартная практика.
doubleValue.ToString("G17");)Разница не в точности double, а в точности выполнения «внутренних»/«промежуточных» арифметических операций внутри процессора. Это поведение платформо-зависимо: на x86 используется x87 FPU, на x64 — SSE2.
Обратите внимание, для хранения значения точности double хватает. dotnetfiddle.net/rVcV1U
То есть, как это ни странно NaN — формально как раз число.
Грубо говоря, функция
isNaN(value)эквивалентна(value === NaN), если бы не одно но: NaN неравен сам себе, поэтому-то и запилили эту функцию.IEEE 754 double-precisionakabinary64) хватает точности без ошибок представлять любое целое число вплоть до Number.MAX_SAFE_INTEGER (9007199254740991 = 2^53 - 1). В С# поведение double идентично.Просто нужно отвязать физику от requestAnimationFrame. И считать её с фиксированным шагом, отдельно от рендера. Как это сделано, например, в Unity.
Обычная человеческая слабость. Бесполезная, не конструктивная, но, мне лично, понятная.
Да и просто, загрузка кода on-demand может быть полезна в некоторых сценариях.
Да это же typescript, только без типов!
В случае с ДЦ во Франкфурте наоборот — из 32 IP всё оказались доступны.
Дело в том, что
это антипаттерн, которого рекомендуют всячески избегать. Ведь вы никогда не узнаете, если что-то другое неожиданно сломается внутри try блока.
Считается, что допустимо использовать try/catch при выполнении трех условий:
Но всё это совершенно не оправдано в нашем случае. И не красиво.
А вот функция
clampNumber()— вполне self-explaining code. Ведь вам сам API как бы говорит: «программист, позаботься о том, чтобы громкость была в интервале от 0 до 1, иначе я ломаюсь».В нормальных (ирония) языках вроде C, где есть отдельно целочисленные и плавающие типы, такое поведение — обычное дело. Там никого не удивишь, что 0.0001 + 0.0002 != 0.0003. А в javascript число представлено одним универсальным типом IEEE 754 binary64. Что позволяет однозначно закодировать (в том числе и) диапазон целых чисел от
Number.MIN_SAFE_INTEGERдоNumber.MAX_SAFE_INTEGERи как будто бы ожидать от number поведение, свойственное для integer в других языках:123 + 456 == 579строго. И это ослабляет бдительность. Ведь по-прежнему0.1 + 0.2 == 0.30000000000000004А в нашем случае вообще происходит итеративное сложение, которое за каждую операцию накапливает в себе ошибку. Так что это поведение абсолютно нормально. Чтобы видеть красивые ровные проценты в UI — отображаемое значение необходимо округлить. Это стандартная практика.