Как стать автором
Поиск
Написать публикацию
Обновить

Posit-арифметика: победа над floating point на его собственном поле. Часть 1

Время на прочтение12 мин
Количество просмотров14K
Ненормальное программирование*Open source*Программирование*Анализ и проектирование систем*Математика*
Перевод
Всего голосов 30: ↑29 и ↓1+28
Комментарии17

Комментарии 17

Жаль только то, что на внедрение нового стандарта в железо потребуется несколько лет. Компиляторы я думаю быстрее будут готовы.
Комментарий пока не оценивали0

Замечательная тема перевода!


Но читать тяжело, описание местами непонятное. Например, нигде не даётся определение числу es, и поэтому что такое useed (useed = 2^(2^es)), тоже не сразу понятно.
Наверно, описание нужно было начать с кратких определений unum Type I / unum Type II / posit / valid, и сразу привести ту формулу "sign(p) * useed^k * 2^e * f".


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


И тут возникает вопрос, почему автор формата выбрал для записи расширения экспоненты фактически унарную запись (00..01, 1111...10), а не более компактный и удобный железу бинарный код. Неужели унарная запись компактнее?

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1

Безусловно.

Всего голосов 1: ↑1 и ↓0+1
Ну значит можно ужать это поле с унарной формы до бинарной?
Комментарий пока не оценивали0

Нет, нельзя.

Всего голосов 1: ↑1 и ↓0+1

Ужать так просто нельзя, нужно же как-то понять, где кончается порядок и начинается мантисса.
Можно записывать порядок кодированием Элиаса, но для порядков из IEEE floats он оказывается короче записи с фиксированным числом битов только когда порядок очень близок к 0. Правда, с некоторой потерей точности относительно IEEE можно записывать экстремально большие и экстремально маленькие порядки (http://helper.ipam.ucla.edu/publications/bdcws2/bdcws2_15049.pdf, слайды 16-17).

Всего голосов 2: ↑2 и ↓0+2
А я правильно понял, что все эти манипуляции с режимом нужны для того, чтобы упаковать первые 4 бита экспоненты в 3 бита?
Комментарий пока не оценивали0

Нет, здесь экспонента имеет переменный размер, который и задаётся режимом.

Комментарий пока не оценивали0
Он задается режимом или режим следует из того, что первые несколько бит могут быть нулями или единицами? Я так понимаю, мы делаем как бы run length encoding, чтобы чуть расширить динамический диапазон чисел? Мне кажется, там какая-то простая идея, которую можно просто объяснить, но сначала нужно понять :)
Комментарий пока не оценивали0
Как бы режим кодирует с помощью такого кодирования количество бит экспоненты. Таким образом мы получаем небольшой выигрыш в точности, когда экспонента близка к нулю, т.е. само число близко к 1. Для этого узкого диапазона в середине точность posit выше, чём float. Но дело в том, что для очень больших или очень малых чисел показатель экспоненты будет большим, число бит режима тоже, и на мантиссу останется меньше бит, чем у float. В этом недостаток формата posit.
Комментарий пока не оценивали0
> Одна из причин, по которой IEEE float не даёт идентичных результатов на различных системах является то, что для элементарный функций, таких, как log(x) и exp(x), по стандарту IEEE не требуется точности до последнего бита для любого возможного входа.

Интересно, давно отменили? :sarcasm:
В версии 2008 требуется (пункт 9.1), а более новых пока не выпускали.
(Не надо вспоминать промежуточное более длинное хранение в x87 и аналогах: во-первых, оно, наоборот, точнее, во-вторых — не стандарт.)
Вот такие вот «хитрые» диверсии убивают всё доверие к авторам.
Всего голосов 1: ↑0 и ↓1-1

Из этой статьи всё равно наполовину ничерта не понятно!!!


Что за бред написан вот в этой фразе
"режим означает масштабирующий фактор, равный useed^k, где useed = 2^2^es"
При том, что величина es не определена!
Вот вам некая таблица, вот и делайте с ней, что хотите.


Можно же было СРАЗУ сказать, что формат позит определяется ДВУМЯ величинами


  • общее количество разрядов
  • количество разрядов экспоненты

Итого, 1 разряд на знак, es на экспоненту, а (разрядность-1-es) — на убер-множитель "режим" и дробную часть?


Какой вообще смысл в 3-битных или 5-битных позитах?


Авторы что-то гениальное знают, тащатся с этого, а остальные трахайтесь как хотите.

Комментарий пока не оценивали0
Не переживайте, ничего гениального авторы не знают. Основная задача posit — выступать в роли «священной коровы» и обеспечить авторам чувство собственного величия. Независимые эксперименты показали (раз, два), что практическая ценность posit стремится к нулю. Если нужно просто уменьшить поток числовых данных — так алгоритмы сжатия данных существуют, как с потерями, так и без, и изобретать для этого новые форматы чисел нецелесообразно.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr