Комментарии 89
Оба примера — хорошая демонстрация недостатков posit, но оба они искусственно натянуты. Что, к примеру мешает в апроксимации Паде посчитать posit(a/b) вместо того чтобы использовать posit(a)/posit(b) где a и b — числа порядка 10^20?
«Что мешает использовать вместо варианта 1 вариант 2» — это тоже натягивание.
А так да, то что надо остерегаться некоторых граничных случаев — это проблема posit
Если вендоры вдруг поймут всю красоту позитов и уберут аппаратную поддержку IEEE 754, то серьёзный вопрос — а a / b каким образом считать?
Если вендоры вдруг поймут всю красоту позитов и уберут аппаратную поддержку IEEE 754, то серьёзный вопрос — а a / b каким образом считать?
Во первых:
«Вдруг» поддержку IEEE 754 никто не уберет.
Вон еще даже COBOL жив (и вычислительные его возможности этому поспособствовали).
Во вторых:
В отсутствии аппаратных возможностей — все прекрасно реализуется через программную эмуляцию. Это широко практикуется еще со времен, когда математический сопроцессор покупался за отдельные деньги (причем включение эмулятора было реализовано незаметным для программы образом, программа думала, что на математическом сопроцессоре работала). И реализовано даже для таких объемных по коду вещей как 3D графика (Mesa), что уж говорить про несколько базовых математических операций.
Собственно автор статьи эту эмуляцию и использовал, только он эмулировал наоборот — новый стандарт.
В общем, описанной вами гипотетической проблемы нет. И не будет.
posit(a/b) вместо того чтобы использовать posit(a)/posit(b)
А в чем тут неправильность? Все вычисления проводятся с числами в Posit, разве это плохо?
Я не знаю С++, но кажется все значения приводятся к типу Т. Также смог найти что оператор деления переопределен для Posit.
posit(a/b) — одна.
В данном же случае a и b специально подобраны так чтобы округление для posit(a) было очень неточным.
прямая подстановка коэффициентов из матлабовской формулы дала бы другой результат.Безусловно другой, и возможно даже с соизмеримой с float точностью. Но у других аппроксимаций вполне могут получится полиномы вида x +105 x2 + 1010 x3 и тогда никакие трансформации их не спасут.
И вы хотите сказать — просто не используйте схему Горнера при вычислениях с posit? Ну хорошо — раз нельзя использовать схему Горнера, значит возможно, что-то ещё нельзя. Где список всего того, что нельзя — с учётом того, что авторы недостатки своего формата отрицают?
Проблемы у posit никто не скрывает — они начинаются при использовании коэффициентов больше 10^6. Что да, тоже бывает, но которых в данном случае в исходной формуле не было. Домножением числителя и знаменателя в формуле на число с величиной более 10^20 Вы элегантно решили эту проблему. Однако то что в результате вышла формула в которой будут явные проблемы с posit видно невооруженным взглядом :).
и тогда никакие трансформации их не спасут.
Такие полиномы осмыслены только для x << 1. Вводим y = x/10^5 и считаем формулу для y. Результат к слову будет для float/double тоже точнее.
Проблемы у posit никто не скрываетЦитирую:
«Числа posit имеют большую точность, больший динамический диапазон и большее покрытие. Они могут использоваться для получения лучших результатов, чем float той же разрядности, или (что может быть ещё большим конкурентным преимуществом), тех же результатов при меньшей разрядности… Так как они работают как float, а не как интервальная система, они могут рассматриваться как прямая замена float»
Вот и я прямо заменил float на posit.
Posit МОГУТ давать большую точность? Могут. В ваших же экспериментах это видно. При прямой замене float на posit. ВСЕГДА ЛИ они будут давать большую точность? Очевидно что нет, не всегда и это вроде никто и нигде не отрицает. Какой сценарий чаще встречается для реальных задач? Авторы считают что их.
Чтобы что-то внедрить быстро — нужно чтобы у него были принципиальные и важные преимущества (как у сотового телефона), чтобы внедрить медленно — нужны заметные, но не критичные преимущества, желательно без недостатков (или с мизерными недостатками) (пример VVTi и прочие фазовращалки в ДВС). А если что-то не лучше существующего и уже распространённого варианта — его внедрят единицы, которым вот так уж получилось именно это сочетание плюсов/минусов поможет… Готов поверить, что этот posit внедрят в какие-то математические библиотеки для отдельных очень тяжёлых алгоритмов рассчёта.
x=1
-------------------------
0.841470984807896 sin(x)
0.841470984807896 double
0.841470956802368 float
0.841470986604690 posit
x=10
-------------------------
-0.642458796040545 double
-0.642459392547607 float
-0.642386730760335 posit
x=100
-------------------------
-35435.826218351600000 double
-35435.824218750000000 float
-35367.474609375000000 posit
x=1000
-------------------------
-391247.500187484000000 double
-391247.500000000000000 float
-265990.968750000000000 positПростите, но ведь у вас разложение в полином сделано для интервала [-2..2]? В таком случае нельзя использовать sin(10) для оценки погрешности вычислений: мы не знаем, насколько велика аналитическая погрешность(отклонение sin(10) от pader(10) ).
Вы используете double как точное значение, но ведь у него тоже есть погрешность. Для чистоты эксперимента было бы круто вычислить точное значение pader(10). Правда, не представляю как это сделать :-) Интуиция подсказывает, что скорей всего это не сильно изменит дело, но она часто подводит...
На мой дилетантский взгляд, вы не совсем правы.
Во-первых, мы считаем не posit(a)/posit(b), а posit(a)/b_as_posit. У нас одна операция преобразования типа и одно деление. Отдельный вопрос, теряется ли точность при приведении конкретно этих чисел в posit. Возможно, Refridgerator сможет ответить на этот вопрос (равны ли 363275871831577908403200.0 и posit(363275871831577908403200.0), ну и все остальные коэффициенты). То есть не три операции с потерей точности, а одна или две.
Во-вторых, операция деления переопределена для posit-ов. Мы проверяем потерю точности при операциях с такими числами. Если же мы считаем posit(a/b), то узнаем потерю точности перевода в другой формат, не более.
В-третьих, я склонен согласиться с вами: деление двух многочленов высокой степени приведет к гораздо большей потере точности, чем расчет по формуле аппроксимации Паде. Независимо от того, какой формат чисел используется.
b_as_posit подразумевает округление b к ближайшему posit. Почему мы не должны учитывать эту операцию округления? Она даёт весьма заметный вклад в результат.
То что posit не всегда лучше довольно очевидно. Вопрос в том лучше ли он для практических задач и несколько сложно обойти его проблемы там где он работает хуже.
b_as_posit подразумевает округление b к ближайшему posit. Почему мы не должны учитывать эту операцию округления?
Да, вы правы, b_as_posit != b_equal. Но я считаю, что лучше когда мы получили b_as_posit не как округление b_as_double к ближайшему posit, а как выполнение операций над posit-ами. Так как заявленная цель — посчитать накопление ошибки в операциях над posit-ами, то на каждой итерации "округление" posit(b_as_double) нам будет мешать.
Если мы можем тривиально посчитать posit(a/b), причём ни a, ни b нас не интересуют, то расчёт через posit(a) /posit(b) требующий три операции округления на мой взгляд просто искусственная пессимизация
На мой взгляд, расчет posit(a/b) привносит ошибки другого формата чисел: на самом деле считается posit(aAsDoubleWithErr/bAsDoubleWithErr) == posit(resultAsDoubleWithMOREErr). И трудно сказать, как связаны ошибки деления double-ов, ошибки конвертации и ошибки posit-ов.
Цель же сравнить одни и те же операции над разными форматами. Поэтому пусть эти вычисления не оптимальны, но они отличаются только типом, мы оставили только один тип ошибок и изучаем только его.
Нельзя делить posit на posit?
Желательно при использовании posit масштабировать вычисления к числам в диапазоне 10-6...106.
На практике это означает, что, если сложная физическая задача разбивается на несколько подзадач, для каждой из них нужно подгонять свою систему измерения, а потом их сопрягать. Казалось бы, при чём тут Mars Climate Orbiter?
числа, близкие к 1 по абсолютной величине, имеют большую точность, чем очень большие или очень маленькие числа, которые гораздо реже встречаются в вычислениях.В том смысле, что ничуть не реже такие числа встречаются, а может даже и чаще.
Вообще тут можно было бы сказать, что на каждую задачу свой инструмент, только вот IEE 754 реализован в железе практически везде, так что сложно представить задачи, в которых использовать Posit будет выгоднее. Не говоря уже о том, что сам новый формат сильно сложнее, чем классический (ну или мне так показалось), что скажется на скорости аппаратной реализации (если она будет) и, возможно, на простоте использования и отладки.
только вот IEE 754 реализован в железе практически вездеЧуть-чуть повздыхаю: в железе практически везде реализована часть IEE 754, а именно бинарные типы. Что же касается таких типов как decimal32, decimal64, decimal128, то они реализованы в относительно экзотических процессорах (POWER и RISC-V). Так что сейчас если хочется честной десятичной арифметики, то приходится так или иначе прибегать к эмуляции. Несмотря на то, что в IEE 754 нужные типы как бы есть.
Разве что в банковской сфере поможет, или как?
Все финансовые расчеты, весь бухгалтерский учет по-хорошему должен делаться в десятичной арифметике с использованием правил десятичного округления, а не двоичного. Сейчас ради этого при выполнении финансовых расчетов идут на всяческие ухищрения (используют высокоуровневые эмуляции того или иного рода).
Вообще говоря, двоичные вычисления как раз почти никому не нужны. Просто в подавляющем большинстве задач детали округления и количество значащих цифр в результате не очень существенны, поэтому особой разницы в том, была ли использована двоичная или десятичная арифметика нет и поэтому все привыкли относиться к двоичным вычислениям, которые нам обычно предлагают по-умолчанию, как к чему-то самом собой разумеющемуся или даже "единственно правильному".
ведь и диапазон значений очень сильно урезается
Нет, не сильно. IEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая. См. вики.
Как только оказывается, что fixed point вам не подходит (так как в одном типе могут быть и очень большие и очень маленькие значения), то сразу появляется необходимость постоянно контролировать положение точки, следить за переполнением и т.д. В конечном счете получаете в том или ином виде эмуляцию десятичной арифметики с плавающей запятой.
Пример проблемной ситуации: вам хочется в одном типе данных хранить суммы в Биткоинах (в том числе очень маленькие значения, 0.00000001 и меньше) и в Зимбабвийских долларах (очень большие значения, триллиарды и больше). Fixed point с целым числом вам не подойдет — ему не хватит значащих цифр (19 десятичных значащих цифр в эквиваленте для int64).
Тут уже идея хранить в одном типе данных такие разные значения является той исходной диверсией, которую надо избегать всеми средствами. Если нормальный язык, то в нём не должно быть проблемы сделать что-то в духе
template <class CurrencyName, int DigitsAfterDot>
class Currency<CurrencyName, DigitsAfterDot> {
private:
intmax_t mValue;
...
};
struct ZimbabweDollar : Currency {
};
using ZimbabweCurrency = Currency<ZimbabweDollar, -6>;
и не допускать конверсию даже между разными представлениями одной валюты без явного оператора конверсии с заданным округлением и с контролем переполнения.
> следить за переполнением
Лучше и проще следить за явным переполнением, чем за молчаливой потерей точности (если мы всё ещё о финансах, где в бухгалтерии каждая потерянная копейка это основание выть на несхождение баланса).
> и в Зимбабвийских долларах (очень большие значения, триллиарды и больше)
Что, там до 10^21 дошли? :)
Они нужны ровно там, откуда возникли — из математических расчётов физического (или близкого к нему) происхождения.
Двоичный порядок на длинных расчётах значительно выгоднее десятичного из-за меньших потерь при округлении.
На коротких расчётах при десятичном вводе/выводе это, конечно, незаметно, за счёт проблем переквантования. Но так как, например, АЦП сейчас чаще генерируют двоичный выход, чем какой-то другой, десятичный транспорт всё равно лишний.
Для бухгалтерского учёта плавающая точка тоже плоха — если вы, например, в decimal32 подсчитаете 9999999+4 и молча (ну, inexact flag подымет, если умеет) получите 10000000 вместо 10000003 (потому что в нём ровно 7 десятичных цифр)… лучше бы вылетело грубое переполнение, на нём было бы лучше заметно, что что-то не так. Поэтому там наиболее желательный вариант это фиксированная точка (копейки, сотые доли копеек, где как лучше).
В итоге, десятичная плавучка остаётся только для задачи «нам нужно точно поддерживать decimal(n,m) из SQL, PL/1, etc., но нам лень самим это делать».
> IEEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая.
Нет, IEEE754 даёт два равноправных варианта рядом — с двоичной и десятичной мантиссой (последняя — через Chen-Ho BCD). Это и по вашей ссылке сказано.
Реализация с Chen-Ho BCD это у IBM? Я их не щупал. Но она не единственная, и для железа IMHO практически всегда удобнее использовать не BCD, а с двоичной мантиссой. Есть какие-то примеры, когда BCD действительно удобнее?
Они нужны ровно там, откуда возникли — из математических расчётов физического (или близкого к нему) происхождения.
Спросите у математиков и физиков, нужны ли им именно двоичные расчёты при прочих равных? Если десятичные или, например, троичные будут обеспечивать ту же точность, скорость, стоимость не будет ли им всё равно что "под капотом"?
Проблема в том, что этого «если» не будет. То, что чем меньше основание для порядка, тем меньше ошибки округления, это банальный доказанный факт. Если бы было основание меньше 2, пытались бы его применить, но меньше не бывает (дробные не считаем, реализация усложняется просто чудовищно).
Математикам и физикам не нужны именно двоичные расчеты. Им нужны либо приближенные расчеты, либо точные.
Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет "под капотом" — им всё равно.
Для точных же вычислений нужно, чтобы при невозможности точного представления числа система явном образом сообщала об этом либо чтобы вообще не допускала ситуацию, когда потеря точности возможна. Но эта задача к обсуждаемой к теме не относится.
Конкретно двоичная арифметика нужна, например, в криптографии. Но в первую очередь потому как современная криптография вся построена вокруг двоичной аппаратной базы. Да и требуется там обычно только целочисленная арифметика. Опять мимо.
Да.
> Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет «под капотом» — им всё равно.
И вот тут оказывается, что именно основание 2 минимизирует ошибки округления, потому что оно минимальное из возможных. Двоичность как таковая тут ни при чём — потому что, например, реализация плавающей точки в S/360, которая двоичная, но с основанием 16, значительно больше теряет при округлении.
> Конкретно двоичная арифметика нужна, например, в криптографии.
Если речь про алгоритмы симметричного шифрования типа DES/AES/много их, то там слово «арифметика» неуместно, это манипуляции с битовым представлением. Если про RSA, ECDSA и прочие, то там целые числа, и неважно, как представляются — это дело компьютера.
так что сложно представить задачи, в которых использовать Posit будет выгоднее.Если бы была реализованна поддержка в железе то легко, графика практически всё в комп графике попадает под диапазон 10^-6...10^6
Вроде как предполагается, что это именно хранение в памяти, регистры в другом формате, и они 512 бит. Заточен на цепочки/циклы регистровых вычислений.
В том смысле, что ничуть не реже такие числа встречаются, а может даже и чаще.
Для posit32 «близкие к единице» — это от 1e-6 до 1e+6. (2^-20...2^+20).
Не говоря уже о том, что сам новый формат сильно сложнее, чем классический (ну или мне так показалось), что скажется на скорости аппаратной реализации (если она будет)
Реализация собственно FP-блока даже проще, там просто добавляется, грубо говоря «распаковка» из posit в float, затем собственно вычисления и «упаковка» результата обратно. На фоне сложности самого FP-блока эта распаковка-запаковка минимальна.
Вот отличная статья на тему: hal.inria.fr/hal-01959581v3/document
На фоне сложности самого FP-блока эта распаковка-запаковка минимальна.Не сказал бы. По количеству транзисторов — может быть, но вот latency она ухудшит раза в два. Еще и сам FP-блок должен быть шире, ибо потенциально у поситов может быть больше битов мантиссы.
Собственно, первое, что стоит сделать для приближения формата к железу — это выкинуть дополнение до двух для отрицательных чисел. Сразу серьезно уменьшит latency.
Для posit32 «близкие к единице» — это от 1e-6 до 1e+6. (2^-20...2^+20).А, ну ОК.
там просто добавляется, грубо говоря «распаковка» из posit в floatЭмм, так а куда тогда пристроить повышеную точность Posit'а, если операции будут выполняться с обычными float'ми? Размерность операций повышать что ли?
В соседней статье приводится рекуррентное соотношение Мюллера
он создаёт математические задачи, которые «ломают» компьютеры. Одна из таких задач — это его рекуррентная формула.
В этой же статье скрипт на Питоне для float дает ошибку на 13 итерации.
С одной стороны, эта формула искусственная в том смысле, что создана для демонстрации проблем с округлением. Возможно, она нацелена именно на текущий формат хранения чисел.
С другой, ряд должен сходиться к числу 5 (небольшое число), используются только базовые арифметические операции, и ошибка проявляет себя довольно быстро.
Было бы интересно увидеть, как ведет себя Posit на этом примере. Уважаемый автор, вас не затруднит провести тесты и рассказать о результатах?
P.S. Согласно статье, числа с фиксированной точкой на 23 шаге выдают неверный результат. Не уверен, имеет ли в данном случае значение язык (не знаю "внутренности" ни Python, ни С), но примерное представление получить будет возможно.
4.64475
4.77073
4.85972
4.99343
6.59878
30.0151
88.4203
99.3479
99.9673
99.9984
99.9999
100
100
100
4.64474
4.77053
4.85545
4.90575
4.84165
2.8218
-71.0303
111.99
100.534
100.027
100.001
100
100
100
4.64474
4.77054
4.8557
4.91085
4.94554
4.96696
4.98004
4.98791
4.99136
4.96746
4.42969
-7.81724
168.939
102.04
С одной стороны, эта формула искусственная в том смысле, что создана для демонстрации проблем с округлением.С другой стороны, подобные проблемы возникают сплошь и рядом при численном решении дифференциальных уравнений в реальных задачах, поэтому в математике и физике так важно получать именно аналитические решения. Синусоиду тоже (в теории) можно вычислить рекуррентно, используются лишь базовые арифметические операции. На практике она либо затухнет в ноль, либо пойдёт «в разнос» и вывалится в ± бесконечность или NaN.
ряд должен сходиться к числу 5 (небольшое число), используются только базовые арифметические операции, и ошибка проявляет себя довольно быстро.Ошибка проявляется быстро, потому что эта формула критична к ошибкам округления при делении. Если, например, при каждым делении количество верных разрядов будет уменьшаться в 2 раза, то 32→16→8→4→2→1→конец.
исходный код для проверки и критики.
Я не знаю С/С++/С#, проверяльщик из меня так себе. Но для интереса глянул код.
- В библиотеке в op1.cpp в функции op1_sqrt дробная часть вычисляется приближенно, рядом из 100 членов. Я сомневаюсь, что это хорошая идея: логичнее задать минимальную точность EPSILON и вычислять ряд until ( abs(rn) < EPSILON). Возможно, я неправ, и есть математическое обоснование, почему корень любого числа достаточно вычислять рядом из 100 членов?
1.1. Кажется, корень не используется в ваших проверках, но стоит ли доверять библиотеке? Особенно в свете того, что для запуска вам пришло что-то там исправлять. Корректно ли там реализованы другие операции? - В вашем коде при умножении комплексных чисел вы используете угол поворота, его синус и косинус типа double. На этом этапе вычислений мы получим эти значения с некоторой погрешностью. Потом мы создаем из них Posit числа. Получается, мы тестируем не чистую Posit математику, а некоторую смесь Posit(double).
2.1. В качестве примера возьмем результат для N=4, lenght=10^10. Если я все верно понял, при N=4 имеем угол 90°, то есть sin=1, cos=0. Умножение-сложение чисел 0, 1 и 10^10 друг на друга 4 раза у вас выдает 9216 — что очевидно неправильно.
2.2. Я осознаю, что в библиотеке нет тригонометрических функций, но можно выбрать такие углы поворота, что sin и cos будут рациональными числами. Тогда их можно будет задать явно. Думаю, sin=0, cos=1 не покажет ничего, а вот sin=1/2, cos=1/2 (угол 45°) было бы интересно посмотреть.
2.3. Цель — не облегчить испытания для Posit, а избежать ситуации Posit(doubleWithError). Поэтому задаем sin=cos=0.5 для всех трех "конкурсантов"
2.4. Как по мне, удлинение вектора переносит ошибку с младших разрядов в старшие (err=1^-38*lenght=1^10), но мало говорит о том, как ошибка накапливается. Было бы интересно посмотреть на сотню-тысячу вращений на 45°.
а вот sin=1/2, cos=1/2 (угол 45°)
Что?!
Теорема Пифагора не освоена?
В 2.2, наверное, не хватает квадратного корня в знаменателе у двойки.
В библиотеке в op1.cpp в функции op1_sqrt дробная часть вычисляется приближенно, рядом из 100 членов. Я сомневаюсь, что это хорошая идея: логичнее задать минимальную точность EPSILON и вычислять ряд until ( abs(rn) < EPSILON). Возможно, я неправ, и есть математическое обоснование, почему корень любого числа достаточно вычислять рядом из 100 членов?Это вопрос к авторам, а корень логичнее, быстрее и точнее вычислять используя метод Ньютона.
Кажется, корень не используется в ваших проверках, но стоит ли доверять библиотеке? Особенно в свете того, что для запуска вам пришло что-то там исправлять. Корректно ли там реализованы другие операции?Это тоже вопрос к авторам. Что-то пришлось исправлять только потому, что компилятор другой.
В вашем коде при умножении комплексных чисел вы используете угол поворота, его синус и косинус типа double. На этом этапе вычислений мы получим эти значения с некоторой погрешностью. Потом мы создаем из них Posit числа. Получается, мы тестируем не чистую Posit математику, а некоторую смесь Posit(double)Да, но у меня не было другого варианта — там нет ни своих синусов, ни конструктора из символьного представления числа.
Получается, мы тестируем не чистую Posit математику, а некоторую смесь Posit(double).
Любой posit32 имеет точное предоставление в double, так что здесь это не существенно
На мой взгляд, проблема в том, что этот double получен в результате вычислений и поэтому содержит некоторую ошибку. Пример с поворотом на 90 градусов в этом смысле очень показателен. То есть мы сначала задали некоторое произвольное отклонение, а потом смотрим на ее поведение. Для меня это отличается от задачи как быстро ошибки вычислений/округлений в pure posit приведут к погрешности, большей чем ошибки вычислений в pure float.
Возможно, вычисление сходящегося бесконечного ряда будет более чистым экспериментом. Во-первых, процесс итеративен. Во-вторых, мы можем отличить погрешность расчета от погрешности округлений. Например, 1/2+1/4+..1/n^2 сходится к единице. Ошибка расчета не должна превышать последний член. Зададим n=100,1000 и сравним отклонения. Имеет ли этот тест недостатки?
Другой отличный тест — специальная рекуррентная формула, в которой posit отказывает так же быстро, как и float.
можно выбрать такие углы поворота, что sin и cos будут рациональными числами.Оба — нет, нельзя, либо sin, либо cos. И рациональность в данном случае не принципиальна. Чтобы на этом тесте posit давал лучший вариант, нужно чтобы sin и cos были рядом (и вектор близкий к единице).
Сегодня утром осознал, что кроме неинтересных случаев с (0;1) ничего не получится. Мотивация использовать рациональные числа в том, чтобы вычисления начинались с posit, а не posit(double_with_error). Мне не интересно вытащить posit в лидеры, мне интересно продумать такие тесты, которые будут сравнивать два формата в идеальных условиях в чистом виде и на более-менее реальной задаче.
Более реальная задача, на мой взгляд — это "крутить" не один круг, а десятки-сотни раз, но с небольшой длиной вектора. Это лучше покажет скорость нарастания ошибки со временем. Хотя не избавляет от проблемы, что вращать мы будем по неидельному кругу, т.к. sin даже в double посчитаем приблизительно.
Более идеальные условия — вращать вектор не по кругу. А умножать на десяток (заранее заданных) комплексных чисел с рациональными коэффициентами. Правда, тут вопросы к реальности задачи.
Вычисление сходящихся рядов, мне кажется, довольно неплохой сценарий. "Хитрая" формула Мюллера (еще раз спасибо! за тест), ряды типа знакопеременного гармонического или ряда обратных квадратов позволяют сравнить отклонение от теоретического значения, но используют числа, меньшие 1.
Еще была идея с итеративным извлечением корня. Этот процесс сходится к единице, можно сравнивать число итераций когда next_sqrt < epsilon. Но в используемой вами библиотеке функция sqrt какая-то сомнительная, и может оказаться что мы измерим расхождения в алгоритмах, а не форматах числа.
Оба — нет, нельзя, либо sin, либо cos.Можно, например 0.6 и 0.8. Только углы уже будут не «круглыми».
А если подобрать количество "оборотов" так, чтобы вернуться? Пусть даже не в единицу, а другое, вычислимое аналитически, состояние вроде (1;1) или (0.5;2) ?
Теоретически алгоритмы нужно оптимизировать под семантику этого posit. Грубо — вы взяли алгоритмы, которые уже пофиксили для IEEE 754, а для posit нужны другие хаки (которые ещё и найти нужно). И при сравнениях надо лезть в битовое представление этого всего.
Даже если результат известен, то всё равно было бы интересно посмотреть на это всё.
template< typename T >
T sin_smp(T x) {
T xx = x * x;
T res = 1.0;
for(int i = 31; i >= 3; i -= 2) {
res = T(1.0) - res * xx / T(float(i * (i - 1)));
}
return x * res;
}
Данный код вы можете добавить в проект, описанный в статье и запустить. Результат такой
**********************
* rational poly test *
**********************
x = 0.5
-------------------------
sin(x) : 0.479425538604203
double : 0.479425538604203
float : 0.4794255495071411
posit wrong : 0.4788961037993431
posit OK : 0.4794255383312702
x = 1
-------------------------
sin(x) : 0.8414709848078965
double : 0.8414709848078965
float : 0.8414708971977234
posit wrong : 0.8424437269568443
posit OK : 0.8414709828794003
x = 2
-------------------------
sin(x) : 0.9092974268256817
double : 0.9092974268256816
float : 0.9092974066734314
posit wrong : 0.9110429435968399
posit OK : 0.9092974290251732
x = 3
-------------------------
sin(x) : 0.1411200080598672
double : 0.1411200080585958
float : 0.1411198079586029
posit wrong : 0.1444759201258421
posit OK : 0.1411200240254402
x = 4
-------------------------
sin(x) : -0.7568024953079282
double : -0.7568024960833886
float : -0.7568023204803467
posit wrong : -0.7614213190972805
posit OK : -0.756802499294281
x = 5
-------------------------
sin(x) : -0.9589242746631385
double : -0.9589243758030122
float : -0.9589247107505798
posit wrong : -0.9691629931330681
posit OK : -0.9589243680238724
Этот результат по-прежнему не опровергает заявленных авторами posit свойств — превосходящую double точность.
В вашей статье Вы работаете с 32 битным POSIT и сравниваете его с 64 битным double? И делаете вывод, что POSIT менее точный? Очевидно, что даже если все 32 бита занять мантиссой их всё равно будет меньше, чем переменной double. Приведите, плз, ссылку, где создатели posit утверждают, что posit32 точнее чем double.
И не опровергает катастрофическое снижение точности при вычислении сильно разных порядков.
Просто по структуре переменной понятно, что она будет плохо работать на больших порядках. Зато сильно лучше около 1. Это же очевидно.
В вашей статье Вы работаете с 32 битным POSIT и сравниваете его с 64 битным double? И делаете вывод, что POSIT менее точный?Потому что авторы заявляют, что их точность соизмерима.
Просто по структуре переменной понятно, что она будет плохо работать на больших порядках. Зато сильно лучше около 1. Это же очевидно.Не менее очевидно, что около единицы фиксированная точка даст ещё более лучший результат — о чём в вашей последней статье вроде бы и говорится. А смысл плавающий точки в том и состоит, чтобы можно было делать вычисления на разных порядках.
Приведите, плз, ссылку, где создатели posit утверждают, что posit32 точнее чем double.Название уже намекает:
Комбинированные операции (fused operations), доступные в posit, предоставляют мощное средство для предотвращения накопления ошибок округления, и в некоторых случаях позволяют безопасно использовать 32-битные числа posit вместо 64-битных float в приложениях, требующих высокую производительность.
Испытания Posit по-взрослому