moontrampolines Oct 2 2018 at 02:19

Самые быстрые числа с плавающей запятой на диком западе

5 min

20K

High performance*Open source*JavaScript*Algorithms*Video cards

+61

Comments 33

ideatum Oct 2 2018 at 07:52

В последствии Dekker показал, что если используются числа с плавающей запятой, использующие округление к ближайшему нечетному числу

Вероятно, имелось ввиду округление до ближайшего четного, этот способ еще называют банковским округлением, из-за того что этим способом принято округлять в банках :)

moontrampolines Oct 2 2018 at 11:59

Точно, спасибо, поправил!

WinPooh73 Oct 2 2018 at 13:20

В банках для счета денег всё же используют никак не числа с плавающей запятой.

ideatum Oct 2 2018 at 14:32

Округление используется не только при операциях с плавающей запятой. В финансовой сфере все-таки иногда приходится делить, но чаще всего банки взымают проценты за операции с деньгами, но меньше копейки/цента взять с клиента не могут, поэтому округлять и приходится. Например, вы хотите перевести 1.50, банк за операцию берет 3%, т.е. 0.045, но 0.5 копейки/цента взять не в состоянии, поэтому округляет. По математическим правилам округлит до 0.05, по банковским до 0.04

Если сумма будет 1.17 то комиссия и по математическим и банковским правилам составит 0.04 (точное значение 0.0351)

agarus Oct 2 2018 at 15:16

Почему так? Смысл?

qw1 Oct 2 2018 at 20:46

Если округлять вверх, банк будет брать процент комиссии больше заявленного, если вниз — то меньше. А так, на большом количестве операций, статистически получается заявленный процент.

moontrampolines Oct 2 2018 at 21:08

Спасибо за уточнение, глянул в вики — поправил картинку тоже. Сутки висела статья, никто не поправил кроме вас.

vesper-bot Oct 2 2018 at 09:09

На картинке немного не множество Мандельброта, которое классическое, а какой-то другой фрактал. Хотя тоже очень красивый.

-1

Wizard_of_light Oct 2 2018 at 10:54

Там вон координаты в левом нижнем углу, можно глянуть. В js по ссылке вроде классический мандельброт.

8street Oct 2 2018 at 10:35

Как-то потребовались расчеты с высокой точностью в астрономии. У меня был всего лишь C# с его biginteger и десяток часов свободного времени. Где-то скачал реализацию класса bigrational в виде дробей, например 1/3. После пары-тройки выражений, действительно, если не округлять, время вычисления вырастает в разы. Тригонометрия считалась за десятки секунд с точностью до сотого знака после запятой. Плюнул, написал свой класс на основе biginteger с фиксированной запятой, реализовал базовые математические и тригонометрические методы. В общем-то, расчеты до 1000 знаков после запятой занимали терпимое время. Такая высокая точность не требовалась, просто её можно было менять практически на ходу. Потом, конечно, узнал, что это все велосипед. П.С. Считал гравитационные взаимодействия.

moontrampolines Oct 2 2018 at 12:33

Как то считал задачу оптимизации и численная производная меньше 1e-5 приводила к возрастанию ошибок, но тоже не знал об этом, вообщем это хороший кейс для различных дифуров, что бы не ждать когда потухнет солнце.

gotz Oct 2 2018 at 14:18

Пока использую BigJS в проекте для просчета активов в портфолио трейдера. Не знал, что она становится тормознее при длительной работе с числами. Попробую посмотреть ваши наработки.

Почему происходит ошибка при парсинге 16 знака числа Пи — не понял из текста? Куда именно смотреть JS-сообществу, чтобы найти причину?

moontrampolines Oct 2 2018 at 14:24

В главной ветке
github.com/munrocket/double.js/blob/master/src/double.js
Или в экпериментальной, пробовал там подключать big.js для разделения числа
github.com/munrocket/double.js/blob/quadtriple/test/test.js

Zenitchik Oct 2 2018 at 14:30

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

Razoomnick Oct 2 2018 at 19:43

Ваш ник и ваш подход к чему-то несчётному идеально подошли к этому посту:
habr.com/company/pvs-studio/blog/312890

Zenitchik Oct 2 2018 at 20:54

Помню эту статью. Читал. Но суть Вашего поста — не понял. Это хорошо или плохо?

Razoomnick Oct 2 2018 at 23:31

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

khim Oct 3 2018 at 00:23

Потому в своё время были изобретены были 80-битные и 128-битные числа с плавающей точкой.

Сегодня, в погоне за «эффективностью» от них отказались… вот только почему-то программы после этого стали тормознее… парадокс…

Zenitchik Oct 3 2018 at 14:03

Я не математик, и не могу проверить это утверждение, но краем уха слышал, что при двоичных вычислениях ошибка, возникающая в следствие округления промежуточных результатов, накапливается медленнее, чем при десятичных.

Deerenaros Oct 9 2018 at 12:02

Да, только пятипалым не так интересен бинарный результат, почему то они хотят увидеть десятичные дроби. Такое преобразование стоит довольно много дочности из-за того, что десять не степень двойки.

Zenitchik Oct 9 2018 at 12:37

Дело в том, что пятипалым нужно видеть только конечный результат, а промежуточные — в десятичную систему преобразовывать ни к чему.

Deerenaros Oct 9 2018 at 22:33

Ну вообще да, я ляпнул немного мимо кассы. Сорре, бывает. Впрочем, есть у двоичной системы есть действительно фатальный недостаток: многие десятичные дроби, вполне естесственные для пятипалых, непредставимы в двоичной системе исчисления с плавующей точкой. Поэтому все финансы в фиксированной. Что творится в военке говорить не буду, премии лишат, но намекну, что кровью плачу часто.

Zenitchik Oct 10 2018 at 12:55

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

mobi Oct 10 2018 at 13:08

Хорошо, рассмотрим такой пример. Вы сделали вклад 100000 руб. под 7% годовых с ежедневной капитализацией. Каков Ваш доход через год в виде рациональной дроби? И нужна ли Вам действительно такая точность?

Zenitchik Oct 10 2018 at 13:29

Каков Ваш доход через год в виде рациональной дроби?

Да легко: 100000 * (7/100) = 7000.

И нужна ли Вам действительно такая точность?

Какая «такая»?

Можете разъяснить суть возражения? Почему не пользоваться для расчётов удобным для расчётов представлением?

mobi Oct 10 2018 at 13:42

Там ключевой момент «с ежедневной капитализацией», поэтому правильный ответ 100000 * ((1+7/(100*365))^365 — 1), а такая дробь представима только в рамках длинной арифметики, т.к. один только знаменатель потребует 365*lb(100*365)=5532 бит.

honor8 Oct 10 2018 at 15:09

Банк не будет считать сложные проценты, а предложит договор, в котором числа (из суммы от процентов) за 2-м знаком после запятой будут отбрасываться. По НДС есть спорные ситуации и разъяснения.

Zenitchik Oct 10 2018 at 15:14

О, пардон. Про ежедневную капитализацию не увидел.

Аргумент принял. Действительно, с рублями не всё так просто.

moontrampolines Oct 9 2018 at 15:55

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

Zenitchik Oct 3 2018 at 16:10

Там проблема была в другом: в разных частях программы время хранилось с разной точностью, поэтому при вычислениях возникала ошибка тем большая, чем большая разность накопилась.

inferrna Oct 3 2018 at 15:06

Если хочется скорости, то можно написать либу на C/C++/Rust и скомпилировать в webassembly/Asm.js. Там и поддержка целочисленных типов будет и скорость повыше.

moontrampolines Oct 3 2018 at 16:18

Я в курсе про такую возможность, но реально ли получить прирост производительности? То есть glsl шейдер я планирую уже юзать, но есть еще один блок кода с длинной арифметикой на флоатах, который можно портировать на wasm.

inferrna Oct 3 2018 at 17:34

Если это работа с массивами, то однозначно будет профит.

Show the best of all time