Да, причину вчерашнего бага я отыскал, но в двух словах это не об'яснить. Тут надо статью писать. Может быть, как-нибудь в другой раз.
Вместо этого расскажу то, что рассказали мне о суммировании чисел. Как известно, точность в компьютере ограничена. Если мы складывает числа примерно одного порядка, то всё ок. Если же числа отличаются на десять порядков, то маленькие числа начинают теряться на фоне больших. То есть:
1e10+1 будет примерно равно 1e10.
Если использовать более точный тип (64 бита вместо 32, или даже ещё больше), то будет доступен больший разброс диапазонов, но ограничения всё равно будут.
Если мы суммируем большой массив, и числа в нём самые разнообразные, то существует риск потерять точность при суммировании из-за явления, которое я указал выше. Если маленьких чисел мало, то пёс с ним. А если у нас большинство чисел маленьких, но есть несколько больших? Потеря точности будет уже более значительной.
И вот какой тут есть совет. Массив надо отсортировать по возрастанию. Тогда в том случае, если маленьких чисел много, они при суммировании станут больше, и уже будут заметнее при сложении с большим числом. Если же суммировать в обратном порядке, то все значения после больших будут просто потеряны.
Вместо этого расскажу то, что рассказали мне о суммировании чисел. Как известно, точность в компьютере ограничена. Если мы складывает числа примерно одного порядка, то всё ок. Если же числа отличаются на десять порядков, то маленькие числа начинают теряться на фоне больших. То есть:
1e10+1 будет примерно равно 1e10.
Если использовать более точный тип (64 бита вместо 32, или даже ещё больше), то будет доступен больший разброс диапазонов, но ограничения всё равно будут.
Если мы суммируем большой массив, и числа в нём самые разнообразные, то существует риск потерять точность при суммировании из-за явления, которое я указал выше. Если маленьких чисел мало, то пёс с ним. А если у нас большинство чисел маленьких, но есть несколько больших? Потеря точности будет уже более значительной.
И вот какой тут есть совет. Массив надо отсортировать по возрастанию. Тогда в том случае, если маленьких чисел много, они при суммировании станут больше, и уже будут заметнее при сложении с большим числом. Если же суммировать в обратном порядке, то все значения после больших будут просто потеряны.
14.03.2025 в 08:22
14.03.2025 в 10:06
Помнится в своё время, когда я еще на пхп писал, мне нужно было умножать НУ ОЧЕНЬ большие числа, то я для себя написал функции, которые не просто умножали и складывали, но хранили числа строго как строки и циклом проходились по "строке", держа в памяти копеечный участок того числа, чтобы избежать всех этих приколов.
Сейчас до сих пор сталкиваюсь с этим, когда эксель в больших числах заменяет все символы после 15-го на 0. Когда ищешь штрихкод, который 32 символа, а эксель все с 16 заменил на 0... Как кошку искать там, где её нет =)