Различия JavaScript Math в разных браузерах

ECMAScript определяет объект Math в JavaScript, однако не гарантирует побитового совпадения каждой математической операции во всех браузерах. Обычные значения JavaScript Number используют формат binary64, поэтому округление является частью числовой модели. Поведение многих операций строго задано, а некоторые математические функции допускают приближение в рамках правил стандарта. Приложению следует определить необходимую точность и проверять этот контракт, а не выводить универсальное поведение браузеров из одного наблюдаемого значения.

Эти детали важны, если результат влияет на решение, сохраняется или передаётся между системами. Десятичное выражение не обязательно точно представимо в двоичной форме, а само значение может пройти разбор, преобразование, форматирование и хранение. Считайте весь поток частью числового контракта приложения. Результат, подходящий для отображения, может не подходить для бухгалтерского учёта или пограничного решения без явного правила округления.

Что задаёт ECMAScript

Различие зависит от операции. Math.exp точно задаёт обработку NaN, бесконечностей и знакового нуля, а для остальных входов допускает приближённый результат реализации. Math.round, напротив, при равном расстоянии до двух целых округляет в сторону положительной бесконечности и сохраняет не конечные и целые входные значения. Это не финансовое правило округления равных расстояний к чётной цифре. Проверяйте контракт конкретной функции, чтобы отличить разрешённое приближение от ошибочного ожидания приложения; не расширяйте все допуски лишь потому, что другая функция Math допускает приближение.

ECMAScript определяет операции объекта Math и их наблюдаемое поведение. Спецификация объекта Math задаёт требования для каждой операции отдельно. Одни результаты определены строго. Другие функции, точные вещественные результаты которых обычно нельзя представить в binary64, могут допускать ограниченное стандартом приближение. Это не разрешение на произвольное значение. Если отличие влияет на приложение, определите конкретную операцию и проверьте её правило, а не обобщайте один пример.

Конечная точность объясняет многие на первый взгляд неожиданные результаты. Двоичная плавающая точка хранит конечную комбинацию степеней двойки, и многие распространённые десятичные дроби не имеют в этой системе точного представления. Поэтому округление возможно во время операции или преобразования. Даже похожие выражения могут округлять промежуточные результаты в разном порядке. Это обычное следствие формата, однако приложение может ошибаться, если предполагает точное десятичное равенство или выбирает неподходящий алгоритм.

Код JavaScript добавляет вокруг Math другие числовые границы. Разбор текста, ввод JSON, неявное преобразование типов, преобразование целых значений в Number и сериализация результата могут повлиять на число до или после математической операции. Если результаты двух браузеров кажутся различными, зафиксируйте ввод и сериализацию и проверьте операцию между ними. Иначе изменившиеся тестовые данные или преобразование можно принять за отличие среды выполнения. Версия браузера сама по себе не объясняет каждый числовой результат.

Контракт зависит и от области приложения. Для денежной суммы, графической координаты и статистической оценки нужны разные диапазоны, точность и допустимая погрешность. Определите правильный результат для пользовательской задачи и выразите правило в тесте. Не превращайте конкретное десятичное отображение или последние представимые разряды одной реализации в случайное требование продукта, если приложение явно от них не зависит.

Приложение должно явно задавать переход от математического значения к тому, которое видит пользователь. Вычисленная величина может быть точнее отображения, и видимая форма не должна незаметно заменять сохранённое значение, если это не предусмотрено правилом. Инструмент измерения может сохранять точность для последующих расчётов, показывая округлённое показание. Для платежа, напротив, может требоваться определённый момент округления до сохранения суммы. Укажите авторитетное представление на каждой границе и применяйте ту же политику к экспортам. Тогда экран, загруженный файл и последующий расчёт не будут расходиться из-за разных неявных преобразований. Контракт зависит от области применения, поэтому тест совместимости браузеров должен проверять правило приложения, а не универсальное число десятичных знаков.

Что учитывать для переносимости

Правила округления на каждой границе должны быть осознанными. Приложение может хранить внутреннюю точность и округлять только при отображении. Система, сохраняющая введённые пользователем десятичные суммы, может вместо этого применять масштабированные целые числа или десятичную библиотеку. Это разные контракты. Раннее округление теряет информацию, а бесконечная отсрочка без правила может привести к непоследовательным итогам. Определите, где значения округляются при сохранении, обмене или показе, и придерживайтесь этого решения во всём процессе.

Порядок операций может влиять на результаты с плавающей точкой. Алгебраически эквивалентные формулы не всегда одинаково округляют промежуточные значения при конечной точности. Поэтому рефакторинг может изменить младшие разряды результата и при этом не нарушить ECMAScript. Если важна числовая устойчивость, выберите подходящий алгоритм и проверяйте его на значимых входах. Специальное исправление для браузера стоит рассматривать лишь после проверки числового требования и спецификации операции. Иначе обходное решение может закрепить случайное ожидание и ухудшить вычисление.

Пограничные сравнения требуют внимания: небольшое различие округления может выбрать другую ветвь. Для решений о допуске, тарификации или безопасности определите обработку равенства и то, происходит ли сравнение до или после округления при показе. Проверьте значения по обе стороны значимой границы. Приложению также нужны правила для нечисловых и бесконечных значений (NaN и ±Infinity), неверных входов и отрицательного нуля там, где они возможны. Явно решите, следует ли отклонить, нормализовать или сообщить о таких значениях, вместо того чтобы полагаться на случайное поведение сериализации и форматирования.

Зависимости и интерфейсы среды имеют собственное числовое поведение. Библиотека может применять другой алгоритм или правило округления, а сервер или база данных могут представлять значения иначе, чем JavaScript. Для передаваемых чисел задайте формат и проверьте полный путь от разбора через вычисления и сериализацию до хранения. Большим целым и точным десятичным величинам может требоваться строковое или структурированное представление вместо общего JSON-числа с плавающей точкой. Локализованный десятичный разделитель меняет отображение, но не базовое значение.

Та же осторожность нужна при пересечении границы языка или сервиса. На сервере целые и десятичные числа могут иметь разные типы, а столбец базы данных может задавать собственный масштаб или диапазон. Преобразование в JavaScript Number и обратно может потерять различия, которые исходная система представляла. Решите, передаёт ли интерфейс целое число, десятичную строку или структурированное значение, и проверяйте его на обоих концах. Проверьте поддерживаемые пределы и полный цикл с сохранением. Если значение предназначено только для показа, обозначьте это и не отправляйте отформатированную строку обратно как вход вычисления. Явный контракт переносимее неявных преобразований браузера и сервиса. Зафиксируйте авторитетное представление после успешного сохранения и используйте его при загрузке. Округлённое отображаемое значение не должно становиться входом следующего расчёта, если это не правило продукта. Синтетические тесты полного цикла покрывают эту границу без личных записей. При выходе за допустимый диапазон сервис должен возвращать понятный результат проверки, а не молча ограничивать значение. Эти решения связывают числовую точность с обычным поведением приложения и делают межбраузерный тест полезным для сопровождения процесса.

Контекст конфиденциальности

Числовые результаты наблюдаемы, но одно значение Math не устанавливает личность пользователя или используемый им браузер. Результат может зависеть от входа, кода приложения, версии среды выполнения и окружающих данных. Считать значение стабильным идентификатором означает вводить необоснованные предположения о слежении и хрупкое поведение приложения. Не собирайте числовые результаты без функциональной необходимости и не связывайте диагностические значения с постоянными записями пользователей без ясной цели и правила хранения.

Диагностика должна соответствовать проблеме. Если пользователь сообщил о неверном вычислении, минимальный пример с синтетическими входными данными обычно лучше сбора исходных записей. Зафиксируйте операцию и версию приложения, а не несвязанные сведения. Если поддержке необходимы реальные входные данные, получите их через подходящий процесс под контролем пользователя, заранее определив доступ и удаление. Храните временные инженерные материалы отдельно от продуктовой аналитики и удаляйте их после завершения задачи поддержки.

Конфиденциальность зависит и от того, что происходит вокруг вычисления. Объясните, остаются ли значения на странице, отправляются ли сервису или сохраняются после задачи. Стандартная библиотека не определяет такое поведение. Не объединяйте диагностику с не связанными данными учётной записи или истории просмотра. Для проверки совместимости могут понадобиться версия браузера и функциональный результат, но это не означает необходимость хранить все вычисленные приложением значения. Собирайте только данные для ответа на вопрос поддержки.

Эта тема касается числовой семантики, а не точности часов или случайных чисел с начальным состоянием. Эти вопросы отдельно рассмотрены в статьях о временных сигналах браузера и детерминированном поведении браузера. Без доказательств не называйте результат Math личным идентификатором, моделью устройства или подтверждением конкретной платформы. Точное описание потока данных приложения полезнее абсолютного обещания приватности или неподтверждённого вывода о платформе.

Это важно для диагностики, которую собирает приложение. В отчёте поддержки с результатом вычисления следует объяснить, зачем он нужен и содержит ли пользовательские данные. Часто операцию можно воспроизвести на созданных значениях, не раскрывающих записи человека. Если поддержке необходим настоящий ввод, ограничьте запрос этим случаем и соблюдайте обычные правила согласия и удаления. Не храните постороннюю историю вычислений только потому, что числа легко записывать: она может раскрыть закономерности действий пользователя, не помогая проверить конкретный контракт приложения. Временную диагностику, привязанную к конкретному обращению, проще проверить и удалить, чем общий журнал всех вычисленных значений.

Воспроизводимые числовые тесты

Начинайте с операций, которые приложение действительно использует. Для каждой задайте типичные входы, ожидаемое поведение в предметной области и правило сравнения. Точное равенство уместно, когда этого требует контракт, например при сравнении целых идентификаторов или специально округлённых значений с определённым представлением. Для приближённых вычислений выбирайте допустимую погрешность с учётом задачи, масштаба результата и ожидаемой ошибки. Одна постоянная погрешность подходит для узкого диапазона, но может быть непригодна для значений разных порядков величины.

В небольшом синтетическом тестовом примере правило округления при равенстве, заданное для Math.round, преобразует вход 2.5 в 3; любой другой результат должен считаться провалом проверки, а не поводом расширить допустимую погрешность. Это проверяет именно данное стандартное правило, а не политику платежей: для расчётов по правилу округления к ближайшему чётному нужны отдельная операция и ожидаемый результат согласно договору выставления счетов.

Если форма оплаты требует сумму, пустое поле должно показать видимое сообщение об обязательном поле и не отправлять форму, а не создавать транзакцию с нулевой суммой. Если в сохранённом счёте каноническая сумма записана десятичной строкой 12.50, обновление форматирования только в браузере не должно менять сохранённую сумму. Если схему хранения нужно изменить, до замены проверьте явную миграцию на синтетических записях.

Проверяйте значимые границы, а не только обычные входы. Включите значения около границ предметной области, ноль, отрицательные значения при их допустимости, величины около поддерживаемого диапазона и неверные или исключительные случаи. Повторные вычисления могут накапливать небольшие ошибки, даже если отдельная операция приемлема, поэтому тестируйте последовательность, которую выполняет приложение. Цель не в каталоге всех возможных результатов Math, а в покрытии ситуаций, способных изменить видимый результат или нарушить контракт задачи.

Проверяйте формат представления во всём интерфейсе. Если значения сериализуются, хранятся или передаются сервису, проверяйте весь путь, а не только расчёт в браузере. У JSON-чисел, форматированных строк, столбцов базы данных и языковых связок свои правила. Определите, какой компонент округляет и как сохраняется точность. Отделяйте локализованное форматирование от числового значения, чтобы десятичный разделитель не выглядел как арифметическое отличие. Если нужна детерминированная сериализация, задайте кодирование на границе приложения и нормализуйте лишь то, что разрешено контрактом.

Тестовые данные должны быть небольшими, синтетическими и связанными с видимым пользователю правилом. Для граничного примера укажите, почему граница важна; для большого числа обозначьте проверяемый диапазон. При анализе изменения фиксируйте версии среды выполнения и приложения, а ожидание связывайте с предметной областью, а не со значением с одной рабочей станции. Разделяйте модульные тесты операции и тесты всего потока от разбора до хранения. Они выявляют разные изменения и дают сопровождающим более ясный следующий шаг. Тестовые данные должны охватывать способы ввода значений, включая пробелы, локальный разделитель и пустое поле. Парсер должен принимать документированный формат или возвращать понятный результат проверки. После разбора отдельно проверяйте математическую функцию и обновляйте пользовательское объяснение при изменении правила предметной области.

Если новая версия меняет числовой процесс, проверьте и сохранённые данные. Решите, остаются ли прежние записи корректными, нужна ли единоразовая миграция или следует сохранить исходное представление. Миграция должна иметь предметную причину и тест на синтетических записях; просите пользователя действовать только при реальной необходимости.

Проверка выпусков браузера

Если обновление меняет числовой тест, оставьте неизменными ревизию приложения, тестовые данные и утверждение, затем сократите первый различающийся пример. Проверьте, задана ли операция строго или допускает приближение. Прежде чем приписывать результат браузеру, изучите преобразования, версии зависимостей, изменения приложения и сериализацию. Если тест предъявлял более строгое требование, чем контракт предметной области, скорректируйте его с явным обоснованием. Не расширяйте допустимую погрешность лишь для устранения необъяснённого отличия, это может скрыть проблему приложения.

При контролируемом сравнении меняйте за раз только одну значимую переменную. Обновление браузера может совпасть с изменением библиотеки ОС, приложения, набора данных или скомпилированного кода. Запишите среду, нужную для воспроизведения, но не собирайте не относящиеся к задаче сведения об устройстве. Если отличие появилось после обновления зависимости или приложения, сравните соответствующие ревизии отдельно. Нет общего правила, приписывающего одно числовое поведение всем браузерам, операциям и выпускам.

Производительность и корректность - разные вопросы. Если вычисление влияет на отзывчивость интерфейса, измерьте пользовательский сценарий на представительных данных и укажите нагрузку. Не превращайте длительность в метку браузера или устройства. На время влияют оборудование, фоновые задачи, питание и изменения среды выполнения, а быстрая работа не доказывает числовую корректность. Проверяйте производительность отдельно, а функциональный результат принимайте по числовому контракту.

По тем же правилам рассматривайте числовые библиотеки, компиляторы и сохранённые данные. Зависимость может изменить алгоритм, компилятор - порядок вычислений, а сохранённое значение могло пройти через иной формат. Поддерживайте небольшой набор регрессионных тестов с объяснением каждого примера и пересматривайте их при изменении требований или поддерживаемых браузеров. Перед выпуском зафиксируйте затронутый сценарий приложения и нужное действие пользователя, не раскрывая его конкретные значения и не обещая универсального побитового совпадения. Проверка выпуска браузера помогает отделить изменения среды выполнения от изменений приложения.

Если выпуск меняет числовой сценарий, проверьте и сохранённые данные, и новые вычисления. Если раньше округление выполнялось на другом этапе, старые записи могут следовать прежнему правилу. Определите, остаются ли они действительными, нужна ли разовая миграция или следует сохранить исходное представление. Не переписывайте сохранённые значения только для сходства с результатами нового браузера. Эти данные мог создать не браузер, а изменение формата хранения может затронуть всех клиентов. Миграция должна иметь обоснование в предметной области, проверяемую процедуру и тест на синтетических записях. Запрашивайте действие пользователя только при необходимости и группируйте регрессионные примеры по назначению, чтобы отделять изменения среды выполнения, зависимостей и приложения.

Публичные источники

• ECMAScript: объект Math
• MDN: Math