Очень интересный формат. Гораздо более экономный чем IEEE-754.
Все кто пользуется числами с плавающей точкой, подмены не заметят. Налететь могут только сериализаторы.
А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
Но пока можно только на FPGA поиграться.
Вряд ли. Грубо, пользователи хотят "смотреть котиков", а петабайты "котиков" на ютьюбе закодированы с использованием старого формата. И перетестировать кучу существующего ПО для просмотра "котиков" на совместимость и отсутствие "багоюзерства" никто не будет. Плюс 100% не будут работать без дополнительных танцев с бубном экспорт/импорт данных во внешние системы, ещё не поддерживающие новый формат (та же сериализация/десериализация).
В теории возможен вариант с появлением принципиально новой архитектуры, которую будет продвигать какая-нибудь крупная компания, причём, помимо прочего, эта компания сможет создать и развивать собственную экосистему с "просмотром котиков", одновременно поддерживая конвертацию стрых данных.
В общем, для существующего пласта ПО и "ближайшей" (лет 10 минимум) перспективы — точно нет.
Так что формат, скорее всего, ждёт довольно узкая область применения, например, в некоторых суперкомпьютерах (если они именно "с нуля" строятся), или при хранении/передаче огромных массивов данных, ну, или если канал сильно ограничен (станции дальнего космоса, например).
Ещё интересный вариант может быть при проектировании видеокарт. На вход идут данные в IEEE-754, а внутренняя обработка уже в posits — обсчётов куча, затраты памяти колоссальные, конвертация входных данных вполне может стать оправданной, при этом результат идёт только на выход монитора, на котором любые а любые мелкие несоответствия обсчёта в двух разных системах заведомо не будут заметны. А там, глядишь, и производители игр подтянутся, а за ними и какие-нибудь производители игровых платформ.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
LVV>>Грядет замена стандарта IEEE-754? P>Не грядет.
Ну, почему?
Лет через 35...
Сначала в каких-нибудь специальных машинах для специальных расчетов.
В графических процессорах...
В суперкомпьютерах...
Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
-
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, почему? LVV>Лет через 35... LVV>Сначала в каких-нибудь специальных машинах для специальных расчетов. LVV>В графических процессорах... LVV>В суперкомпьютерах... LVV>Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
А тут не грозит потому как потребитель платящий деньги разницы не заметит. Возможная экономия на нескольких битах приведет к усложнению схемотехники и снижению быстродействия. Для конечного потребителя это пофиг. А вот для разработчика оценка потери точности стала бы еще сложнее. Для чего несколько лишних бит в мантиссе, если оценка того не потеряются ли они при дальнейших расчетах становится очень нетривиальной задачей?
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, LaptevVV, Вы писали:
LVV>>Ну, почему? LVV>>Лет через 35... LVV>>Сначала в каких-нибудь специальных машинах для специальных расчетов. LVV>>В графических процессорах... LVV>>В суперкомпьютерах... LVV>>Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
Просто сделают доп набор векторных команд и назовут PackedFloat extension вместо posit и понесётся маркетинг.
— P>А тут не грозит потому как потребитель платящий деньги разницы не заметит. Возможная экономия на нескольких битах приведет к усложнению схемотехники и снижению быстродействия. Для конечного потребителя это пофиг. А вот для разработчика оценка потери точности стала бы еще сложнее. Для чего несколько лишних бит в мантиссе, если оценка того не потеряются ли они при дальнейших расчетах становится очень нетривиальной задачей?
Тут как раз все проще и вместо double64 предлагается переходить на posit32 что в два раза быстрее по памяти и гораздо точнее чем float.
Здравствуйте, kov_serg, Вы писали:
_>Тут как раз все проще и вместо double64 предлагается переходить на posit32 что в два раза быстрее по памяти и гораздо точнее чем float.
Чуть-чуть точнее, и стоит немного ошибиться в оценке порядка результатов, в том числе промежуточных каждой операции, так эти небольшие преимущества обернуться полным провалом.
Здравствуйте, kov_serg, Вы писали:
_>Все кто пользуется числами с плавающей точкой, подмены не заметят.
"Отучаемся говорить за всех" (c)
Физики всех видов точно пошлют как минимум куда Макар телят не гонял. Почему они должны терять точность вычислений из-за смены порядка? Постоянно вылазят константы с большими показателями, типа 6.67e-11, 6.02e23 и т.п. — на них будет падать точность расчётов?
_>А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
И кто будет так "нормализовывать" расчёты на практике?
Здравствуйте, netch80, Вы писали:
N>Физики всех видов точно пошлют как минимум куда Макар телят не гонял. Почему они должны терять точность вычислений из-за смены порядка? Постоянно вылазят константы с большими показателями, типа 6.67e-11, 6.02e23 и т.п. — на них будет падать точность расчётов?
Ничего не вылазит.
_>>А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
N>И кто будет так "нормализовывать" расчёты на практике?
Никто в здравом уме и не производит вычисления с не нормализированными величинами.
Вы же не вычисляете расстояние между атомами в парсеках и не измеряете площадь поля для гольфа в барнах. Даже вместо штук зачем-то используют моли.
Здравствуйте, kov_serg, Вы писали:
N>>И кто будет так "нормализовывать" расчёты на практике? _>Вы же не вычисляете расстояние между атомами в парсеках и не измеряете площадь поля для гольфа в барнах. Даже вместо штук зачем-то используют моли.
Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты.
_>Никто в здравом уме и не производит вычисления с не нормализированными величинами.
Сплошь и рядом вижу такое — потому, что никому из практиков в здравом уме таки не приходит, что подложка будет терять точность на минимальных отклонениях от диапазона, грубо говоря, от 1/100 до 100.
Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями.
Здравствуйте, netch80, Вы писали:
N>Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты.
Нет дело не в стандартах.
_>>Никто в здравом уме и не производит вычисления с не нормализированными величинами. N>Сплошь и рядом вижу такое — потому, что никому из практиков в здравом уме таки не приходит, что подложка будет терять точность на минимальных отклонениях от диапазона, грубо говоря, от 1/100 до 100.
Это видимо по тому что они не внимательно изучали численные методы. Или вообще далеки от вычислительной математики.
И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
posit32 vs float32
режим 1 - до 4 8.4 значащих цифр у float 7.2
режим 2 - до 16 7.8 значащих цифр у float 7.2
режим 3 - до 256 7.2 значащих цифр у float 7.2
режим 4 - до 65536 6.6 значащих цифр у float 7.2
режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
...
max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
2^(-2^31) - наименьше по модулю представимое не нулевое число
Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
N>Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями.
Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр. Для более точных моделей ничто не мешает использовать большую точность.
Более того есть методы позволяющие уточнять результат имея ограниченную точность вычислений.
И потом тут как всегда компромис: вам надо точно или быстро.
Здравствуйте, kov_serg, Вы писали:
_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях. _>
_>posit32 vs float32
_>режим 1 - до 4 8.4 значащих цифр у float 7.2
_>режим 2 - до 16 7.8 значащих цифр у float 7.2
_>режим 3 - до 256 7.2 значащих цифр у float 7.2
_>режим 4 - до 65536 6.6 значащих цифр у float 7.2
_>режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
_>режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
_>режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
_>режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
_>режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
_>режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
_>...
_>max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
_>2^(-2^31) - наименьше по модулю представимое не нулевое число
_>
_>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
Следует ли из этой таблички, что, те хвалы обещающие рай на земле, что написаны в статье на хабре — ложь? (Про то, что один 32-битный посит заменяет float64?)
IEEE-754, конечно, уродство ещё то, но я не вижу чем новый формат лучше. Один только отдельный бит знака сводит на нет преимущества нового формата. И как при наличии этого бита он может избежать такой странности, как несовпадающие значения 0 и -0? Not-a-number (NaN), так же как и бесконечности (причём разных знаков) — тоже полезны как результат выполнения функций в которые передаётся недопустимый аргумент. А разная длина мантиссы у разных порядков даже вредна, при этом теряется сам смысл плавающей точки.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, Mystic Artifact, Вы писали:
_>>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях. _>>
_>>posit32 vs float32
_>>режим 1 - до 4 8.4 значащих цифр у float 7.2
_>>режим 2 - до 16 7.8 значащих цифр у float 7.2
_>>режим 3 - до 256 7.2 значащих цифр у float 7.2
_>>режим 4 - до 65536 6.6 значащих цифр у float 7.2
_>>режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
_>>режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
_>>режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
_>>режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
_>>режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
_>>режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
_>>...
_>>max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
_>>2^(-2^31) - наименьше по модулю представимое не нулевое число
_>>
_>>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
MA>Следует ли из этой таблички, что, те хвалы обещающие рай на земле, что написаны в статье на хабре — ложь? (Про то, что один 32-битный посит заменяет float64?)
Нет это не ложь это лукавство. Ибо оно может заменить double по динамическому диапазону, но не по точности. У double мантиса 52бита, а у посита32 28 и меньше.
Но double способен представлять числа до 1.8e308 посит32 тоже способен работать с этими числами, но с меньшей точностью. Но как я уже писал раньше у инженеров только интерферометры способны выдавать очень точные значения, бытовая точность это 1-10%. 10ppm это 5 знаков уже часы. Меньше 1ppm это уже прецизионные измерения. А когда вы оцениваете по порядку величины тут нафиг не нужна великая точность.
Здравствуйте, kov_serg, Вы писали:
_>Но double способен представлять числа до 1.8e308 посит32 тоже способен работать с этими числами, но с меньшей точностью. Но как я уже писал раньше у инженеров только интерферометры способны выдавать очень точные значения, бытовая точность это 1-10%. 10ppm это 5 знаков уже часы. Меньше 1ppm это уже прецизионные измерения. А когда вы оцениваете по порядку величины тут нафиг не нужна великая точность.
Вот, не знаю... Сдается мне, что даже графика в виде "точность то не очень нам и важна, там пару пикселов туда-сюда" на самом деле довольно быстро становится проблемой (хотя я серьезно графикой не занимался). С учетом того, что кардинальных улучшений в точности нет — затея, имхо, сомнительная.
Там меня в статье на хабре на самом деле не только это зацепило. Там написано, что битовые сравнения вдруг работают (с нулем? — с чего бы? А +/-0 вроде и не особо то проблема). Быстро прочитав наискось осталось ощущение, что много восторга, но сложностей работы с FP не уменьшает вообще, а качаственные характеристики не осознал.
Здравствуйте, kov_serg, Вы писали:
_>Это видимо по тому что они не внимательно изучали численные методы. Или вообще далеки от вычислительной математики.
Это знатный аргумент. Сразу выводит в дамки.
_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.
_>[code] _>posit32 vs float32 _>режим 1 — до 4 8.4 значащих цифр у float 7.2
...
... _>режим 9 — до 1.34e+154 3.6 значащих цифр во float не представима _>режим 13 — до 1e+2466 1.2 значащая цифра во float не представима _>...
О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?
_>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов.
_>Для более точных моделей ничто не мешает использовать большую точность.
64-разрядный IEEE-754
Но ради чего пыжились придумывая как скрестить ужа с ежом?
_>И потом тут как всегда компромис: вам надо точно или быстро.
Так все же насколько быстрее?
Здравствуйте, LaptevVV, Вы писали:
LVV>Наши могут себе позволить. LVV>В специальных разработках для государственных структур. LVV>Ну, или для вооружений.
Ага, могут, только все это засекретят, и никто не узнает дают ли они реально улучшение или с ними проблем будет еще больше чем с обычными флоатами...
Вообще текущий стандарт чисел с плавающей точной просто ужасен, там грабли на каждом шагу. Было бы здорово если бы его заменили на что-то более вменяемое.
Но с другой стороны грабли текущего стандарта известны и хорошо описаны, а какие там новые грабли окажутся в новом стандарте пока не понятно, вполне возможно, что их будет еще больше, и понятно это станет только после массового внедрения. А массовое внедрение вещь дорогая, сложная и очень не быстрая...
