Comments 14
Вообще-то, 0,5 (дес) + 0,5 (дес) = 1,0 (дес), даже если они представлены в виде двоичных вещественных чисел.
Это вы о вот этой картинке?
Скрытый текст
Вы обратили внимание, что она перечёркнута? Вы, наверное, пропустили мою первую статью, вот её первый абзац:
Скрытый текст
Недавно мне понадобилось сэмулировать работу с плавающей точкой только при помощи целочисленной арифметики, поскольку флоаты были недоступны. Полез я было в интернет за готовой библиотекой, и чуть не утонул. Мало того, что я не нашёл того, что искал, это бог с ним. Я обнаружил, что в интернете кто-то неправ. :)
Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.
Да, ликбез крайне необходим. Напомнило про https://habr.com/ru/articles/825066/. Там автор выдумал какое-то безумие, где катастрофическая потеря точности возможна почти на каждом шагу, но был совершенно неспособен понять в чем проблема, лишь минусовал карму со словами "решение же аналитическое". Спасибо за ликбез, надеюсь многим поможет.
Оказалось, что лучший способ документировать код C++ — это полностью переписать его на Python :-)
ну как сказать, я вот эти паши питоны вообще тогда прочитать не смогу )
ой, да ладно, я ничего особо питонского там не использовал :)
ну чтобы мне понять написанное придется всё равно конвертировать это в какой-то другой язык, особое - не особое.
Так смотрите непосредственно цпп код, если интересно.
ну я же пришёл статью прочитать, а не лазить где-то и читать что-то.
у вас статья для хабов алгоритмы и С++, а внутри - питон. Если бы я хотел читать статьи про питон и для питона - я бы подписался на соответствующий хаб.
Вы внимательно прочитайте мой комментарий, он написан с цитированием ваших слов, соответственно обозначает конкретную проблему.
ваш тезис говорит о том, что для понимания кода вы конвертировали его в питон и вуаля, всё стало понятно. я вам озвучил контртезис - что написанное на питоне ТЕПЕРЬ непонятно кому-то еще. Мне кажется всё довольно просто?
Известно, что Nvidia не дает эффективно вычислять double на потребительских видеокартах, оставляя только float32 и int32 для работы в играх/CUDA, но, если int64 эмулировать достаточно просто на двух int32. То, интересно как насчет double.
Не получится. Если нет железной поддержки 64-разрядных вещественных, их придётся считать чисто программно, используя целые числа.
Ну, если совсем формально, то можно поизвращаться и, используя 32-разрядные вещественные числа, отдельно считать "младшие половины" и "старшие половины" 64-разрядных вещественных чисел (в кавычках, поскольку, на самом деле, там всё сильно сложней будет), а потом их объединять, только там столько дополнительных целочисленных арифметико-логических операций потребуется, что быстрей уже всё считать с помощью одной только целочисленной арифметики, как это делают в ситуациях, когда процессор не поддерживает вещественную арифметику вообще. Но на графических процессорах с этим много хуже, чем на обычных -- они эффективны, когда над несколькими независимыми потоками данных можно выполнять идентичную последовательность операций, а в данном случае последовательность будет почти всегда индивидуальной (скажем, перед сложением/вычитанием надо сделать выравнивание порядков, и количество сдвигов при этом зависит от разности порядков складываемых/вычитаемых чисел).
В общем, если действительно нужен GPU с 64-разрядной вещественной арифметикой, то без вариантов: надо брать профессиональную железяку за 100500 денег.
Откуда у вас в алгоритме Кэхэна взялась бабушка?
А я ведь даже ссылку привёл.
The algorithm is attributed to William Kahan; Ivo Babuška seems to have come up with a similar algorithm independently (hence Kahan–Babuška summation).
Ликбез о плавающей точке: сложение, катастрофическое сокращение и бабушка Кэхена