IEEE754

[Legioner93]

Munin в сообщении #1419869 писал(а):

Имплементировать в железе это кто будет, Пушкин?

Имплементации в железе уже есть, пока на FPGA и ASIC

Munin в сообщении #1419869 писал(а):

Ни малейшего понимания, что такое FP, и зачем они нужны и используются

No comments. Читайте оригинальную статью https://www.superfri.org/superfri/article/view/137

Munin в сообщении #1419869 писал(а):

IEEE754 - стандарт, появившийся после более 30 лет вычислений с плавающей запятой. Он вобрал в себя огромный опыт архитектур, их использования, и численных методов. Это надо понимать. Он лучше всех других форматов FP, бывших до него или параллельно ему.

И как отсюда следует, что нельзя придумать ничего лучше?

Munin в сообщении #1419869 писал(а):

Единственные его недостатки - это

Читайте статью

-- Ср окт 09, 2019 08:40:22 --

Могу также скинуть в личку свои слайды по Posit, но лучше к первоисточнику

-- Ср окт 09, 2019 08:51:47 --

arseniiv в сообщении #1419874 писал(а):

Хотя могут просто увеличить разрядность (IEEE754)

Один из недостатков IEEE754 --- как раз проблемы с большими разрядностями. Диапазон растёт быстро: почти-достаточные $10^{38}$ на 32 битах, астрономические $10^{308}$ на 64 битах и бессмысленные $10^{4932}$ на 128 битах. А вот точность растёт не так сильно, как могла бы.

[Munin]

Legioner93 в сообщении #1419882 писал(а):

FPGA

для тех, кто понимает, что это значит.

Legioner93 в сообщении #1419882 писал(а):

И как отсюда следует, что нельзя придумать ничего лучше?

Да никак. Можно.

Но для этого надо хорошо подумать.

А не просто брать дурь из головы. Кстати, как раз в стиле подобной дури были первые реализации FP в компьютерах. (Не все, но некоторые.) Те, которые за 30 были признаны неудачными, к моменту появления IEEE754. Но история ничему не учит.

Legioner93 в сообщении #1419882 писал(а):

Могу также скинуть в личку свои слайды по Posit, но лучше к первоисточнику

Да спасибо, я как-то обойдусь.

Legioner93 в сообщении #1419882 писал(а):

Один из недостатков IEEE754 --- как раз проблемы с большими разрядностями. Диапазон растёт быстро: почти-достаточные $10^{38}$ на 32 битах, астрономические $10^{308}$ на 64 битах и бессмысленные $10^{4932}$ на 128 битах. А вот точность растёт не так сильно, как могла бы.

Вот яркий пример некомпетентности.
1) Точность не может расти быстрее, чем число битов. На 128 битах вы не получите точности лучше, чем $2^{-128}.$ Так что не "как могла бы", а просто берите больше битов. Никто не мешает сделать формат на 256 бит, на 1024 бита.

Правда, нужны ещё процессоры и FPU, которые их будут обрабатывать, числомолотилки. И не на FPGA. И не библиотеки на some obscure language.

1.5) Разница между 53 и 64 битами не настолько велика, чтобы было из-за чего плакать. Тем более разница между 113 и 128 битами. 53 в любом случае больше, чем 24, и намного больше. А если почему-то (хотя это крайняя редкость) этого не хватает, всегда доступны 113.
2) Точность сама по себе, как быстро оказалось, никому не нужна. Просто неоткуда взять ни в каких реальных задачах исходных данных точнее, чем $10^{-10}\text{-}10^{-15}.$ А нужны на самом деле устойчивые численные алгоритмы, и контроль погрешности. Ну так это не вопрос к формату представления чисел. И это всё давно уже реализуется, начиная с тех же 60-х - 70-х годов.

В общем, всё это выглядит как желание сделать калькулятор со стразиками. Чего это он без стразиков, некрасивый. Мысль, что калькулятором пользуются для дела, даже как-то не закрадывается в голову.

[Pphantom]

Munin в сообщении #1419915 писал(а):

1) Точность не может расти быстрее, чем число битов. На 128 битах вы не получите точности лучше, чем $2^{-128}.$ Так что не "как могла бы", а просто берите больше битов. Никто не мешает сделать формат на 256 бит, на 1024 бита.

Дело не в этом. Стандарт IEEE754 при четверной точности отводит на хранение экспоненты 15 бит, которые попросту не нужны в таком количестве (с восьмерной, кстати, уже 19, что тем более не надо).

Munin в сообщении #1419915 писал(а):

Точность сама по себе, как быстро оказалось, никому не нужна. Просто неоткуда взять ни в каких реальных задачах исходных данных точнее, чем $10^{-10}\text{-}10^{-15}.$

Надо это нашим небесным механикам сказать, а то они не в курсе. Да и астрометристам заодно.

[worm2]

Имхо, сила IEEE754 — в почти безубыточном переходе между разными единицами измерения (ангстремы в парсеки, вот это вот всё). Однако, если расчёты писать дисциплинированно, обезразмеривать величины и следить за своими, хм... блоуапами, то в ряде случаев, действительно, можно было бы сэкономить на экспоненте. Меньший размер числа = меньший расход памяти = больше влезает в кэш, звучит довольно заманчиво.

[Dmitriy40]

worm2 в сообщении #1419935 писал(а):

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

Для этого есть (были) форматы с фиксированной точкой, положение которой держится "в уме". Но оказалось неудобно программистам: постоянно помнить где именно в данной переменной сидит точка, куда её надо сдвинуть в результате вычислений, постоянно проверять на возможные переполнения и потерю точности (особенно в промежуточных вычислениях), и т.д. Плавающая точка решает почти все эти проблемы, незначительно проигрывая в точности. С появлением нормальной (и быстрой) аппаратной поддержки FP форматы с фиксированной точкой ушли по узким нишам (я например в микроконтроллерах почти исключительно фиксированной точкой пользуюсь так как аппаратной поддержки FP нет, а обрабатывать нецелые значения нужно, но мне обычно 16 бит в переменных и иногда 32 бита в промежуточных вычислениях хватает).

Pphantom в сообщении #1419925 писал(а):

Munin в сообщении #1419915 писал(а):

Точность сама по себе, как быстро оказалось, никому не нужна. Просто неоткуда взять ни в каких реальных задачах исходных данных точнее, чем $10^{-10}\text{-}10^{-15}.$

Надо это нашим небесным механикам сказать, а то они не в курсе. Да и астрометристам заодно.

А можете немного подробнее развернуть? Интересно где могут браться исходные данные с относительной точностью лучше $10^{-15}$. Пока могу вспомнить лишь стандарты частоты/времени, там уже и до 18 цифр добрались, прочие же эталоны известны/зафиксированы с точностью не лучше $10^{-10}$. В Солнечной системе вроде бы точность орбит планет до метров, а это лишь $10^{-12}$ примерно, десятитысячные доли секунды дуги для звёзд это тоже лишь 9-10 знаков.

[arseniiv]

Munin в сообщении #1419875 писал(а):

Какой тонкой оптимизации?

Например может быть польза близкие к единице представимые числа уложить погуще, а далёкие пореже.

[Munin]

Pphantom в сообщении #1419925 писал(а):

Дело не в этом. Стандарт IEEE754 при четверной точности отводит на хранение экспоненты 15 бит, которые попросту не нужны в таком количестве (с восьмерной, кстати, уже 19, что тем более не надо).

Он их отводит, потому что отводит. Ну кому-то не нужны. А кто-то математики, мечтающие вычислять числа Грэма.

В любом случае, потеря просто мизерная, как я уже сказал. Если вы отведёте не 15, а 11 бит (как в двойной точности), то выиграете 4 бита на мантиссу. Это как-то спасёт отца русской демократии? Вместо 113 бит будет 117. Даже если вы отведёте 8 бит (как в одинарной точности), в мантиссе у вас будет вместо 113 бит - аж целых 120. При том, что и 113 обычно весьма избыточно для подавляющего большинства задач, это крохоборство абсолютно ничем не оправдано. В то же время есть пользователи, для которых переход от 11 битов экспоненты к 15 чем-то критично. И таким образом, это совершенно разумный компромисс. (Разумеется, в основном он был разумен при выборе формата двойной точности, поскольку 8 бит реально для многого не хватало. А потом просто взяли простую формулу с логарифмом.)

Pphantom в сообщении #1419925 писал(а):

Надо это нашим небесным механикам сказать, а то они не в курсе. :mrgreen: Да и астрометристам заодно.

Точность опыта Брагинского $10^{-15}.$ Точность эксперимента LIGO тоже где-то в этом порядке. Если у "ваших" небесных механиков и астрометристов другие точности, поделитесь, пожалуйста. Потому что эти цифры вообще-то по всем инженерным и научным областям примерно уровень высших возможностей человечества и примерно одинаковы. Мне будет интересно узнать о каких-то прорывах.

arseniiv в сообщении #1419960 писал(а):

Например может быть польза близкие к единице представимые числа уложить погуще, а далёкие пореже.

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

Может быть, это было бы интересно, как добавочные форматы к стандартной линейке IEEE754. Никто не мешает.

Но в реальности как раз эволюция вычислительных систем шла от большого разнообразия форматов к единству. Советую почитать и ужаснуться: http://www.quadibloc.com/comp/cp0201.htm Floating Point Formats. Всё-таки есть вполне разумные потребности унификации форматов для переносимости как в рамках одной платформы, так и между платформами. И именно они были удовлетворены стандартом IEEE754. А до него были компьютеры, позволяющие до дюжины разных форматов (не более чем четырёх размеров, например), и возиться с ними было просто неудобно. Хотя у каждого формата наверняка были какие-то свои резоны существования.

Я повторяю: IEEE754 - вполне разумный компромисс, выработанный вполне неглупыми людьми на основании реального опыта. Который, может быть, сегодня уже подзабылся.

-- 09.10.2019 21:07:55 --

worm2 в сообщении #1419935 писал(а):

Меньший размер числа = меньший расход памяти = больше влезает в кэш, звучит довольно заманчиво.

В этом рассуждении числа меряются размерами 4 байта, 8 байт, 16 байт. Это слишком грубые изменения размеров. Уменьшение экспоненты столько не даст. Так что нечего на неё рот разевать. Экономия с 8 байт до 4 (или даже до 2) может быть оправдана только уменьшением точности чисел в конкретной задаче.

-- 09.10.2019 21:11:21 --

Dmitriy40 в сообщении #1419950 писал(а):

С появлением нормальной (и быстрой) аппаратной поддержки FP форматы с фиксированной точкой ушли по узким нишам

Ну, они получили некоторый второй расцвет в SIMD и GPU. И наверное, эта ниша уже никуда не денется.

[Dmitriy40]

В SIMD проще пользоваться стандартными типами с плавающей точкой, скорости вычислений уже хватает (т.е. вычисления над целыми не быстрее вычислений над плавающими).
В GPU заметен переход на плавающую точку половинной точности - она удобнее 16 бит целых, а точности 0.1% для графики часто хватает. А когда не хватает - опять же проще взять сразу single чем заморачиваться с фиксированной точкой.

[Pphantom]

Dmitriy40, тут есть дополнительная деталь: итоговая точность результатов далеко не всегда совпадает с промежуточной точностью вычислений, которые нужны для получения этих результатов, "запас" в виде по крайней мере еще нескольких значащих цифр нужен достаточно часто.

Dmitriy40 в сообщении #1419950 писал(а):

Пока могу вспомнить лишь стандарты частоты/времени, там уже и до 18 цифр добрались,

Они, а также связанные с ними вещи (вроде моделей вращения Земли).

Dmitriy40 в сообщении #1419950 писал(а):

В Солнечной системе вроде бы точность орбит планет до метров, а это лишь $10^{-12}$ примерно

А вот тут - не совсем. Бывают задачи, которые можно (и нужно) решать точнее, например, моделирование орбит астероидов, сближающихся с Землей. Там 20-24 значащих цифры - довольно обычное явление, иначе избавиться от накапливающихся ошибок слишком сложно. Плюс есть подсистема Луна-Земля-Солнце, где точность расстояний - сантиметры (и сейчас пытаются добраться до миллиметров).

Dmitriy40 в сообщении #1419950 писал(а):

десятитысячные доли секунды дуги для звёзд это тоже лишь 9-10 знаков.

У "Радиоастрона" и "Gaia" это порядка $10^{-5}$ угловых секунд (и хочется выжать лучше), итого 11 в финальной точности. А при обработке (по крайней мере у Gaia) промежуточные данные считаются с погрешностью еще примерно на шесть порядков лучше.

Munin в сообщении #1419994 писал(а):

В то же время есть пользователи, для которых переход от 11 битов экспоненты к 15 чем-то критично.

А кто именно? Мне тоже интересно.

Munin в сообщении #1419994 писал(а):

Точность опыта Брагинского $10^{-15}.$ Точность эксперимента LIGO тоже где-то в этом порядке.

Отчасти см.выше, но можно и конкретно это обсудить. Улучшать LIGO (и коллаборацию с VIRGO) мы не будем? С eLISA работать не надо?

[Geen]

Эмммм, а это всё в ПРР(М)?...

[Munin]

Pphantom в сообщении #1420005 писал(а):

Улучшать LIGO (и коллаборацию с VIRGO) мы не будем? С eLISA работать не надо?

И чем для этого не достаточно 128-битных чисел IEEE754?

-- 09.10.2019 23:35:37 --

Dmitriy40 в сообщении #1420003 писал(а):

А когда не хватает - опять же проще взять сразу single чем заморачиваться с фиксированной точкой.

Именно об этом я и говорю. Когда IEEE754 реализован и общедоступен - всегда проще взять вместо singl-а double, вместо doubl-а quad - там уже 34 десятичные цифры, на все LIGO и Gaia хватит с большим запасом, до конца 21 века. А вместо quad-а можно взять octuple.

[Pphantom]

Geen в сообщении #1420007 писал(а):

Эмммм, а это всё в ПРР(М)?...

Да, пожалуй. Выделил в отдельную тему (правда, от исходной при этом почти ничего не осталось).

Munin в сообщении #1420008 писал(а):

И чем для этого не достаточно 128-битных чисел IEEE754?

Было бы достаточно, если бы они были действительно хорошо реализованы (в идеале - в "железе"). К сожалению, это чаще не встречается, чем наоборот.

[arseniiv]

Munin в сообщении #1419994 писал(а):

Я повторяю: IEEE754 - вполне разумный компромисс, выработанный вполне неглупыми людьми на основании реального опыта.

С этим-то наверно никто не спорит.

[Dmitriy40]

Pphantom
Спасибо за пояснения.

Munin
Мне показалось Вы утверждали что фиксированная точка получила распространение в SIMD и GPU и уже оттуда не уйдут. Последнее мне и показалось спорным.

[Munin]

Pphantom в сообщении #1420014 писал(а):

Было бы достаточно, если бы они были действительно хорошо реализованы (в идеале - в "железе"). К сожалению, это чаще не встречается, чем наоборот.

В железе они реализованы с 80-х начиная со SPARC V8. Современные чипы - например, POWER9. Кажется, ещё что-то из z/Architecture.

Однако то, о чём мечтаете вы, не реализовано вообще никак (или IBM/390 вы имеете в виду?), так что претензии необоснованы.

arseniiv в сообщении #1420015 писал(а):

С этим-то наверно никто не спорит. :-)

Ну как это! Как раз ровно вы с этим спорите, Legioner93 спорит, Pphantom спорит.

-- 10.10.2019 00:36:00 --

Dmitriy40 в сообщении #1420016 писал(а):

Мне показалось Вы утверждали что фиксированная точка получила распространение в SIMD и GPU и уже оттуда не уйдут. Последнее мне и показалось спорным.

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

Может быть, появится какой-нибудь новый компромисс. Например, векторный формат, в котором одно поле экспоненты и несколько полей мантиссы - для вектора чисел, имеющих одинаковый двоичный порядок (но уж не нормализованных).