Грядет новая арифметика!

[spamsink]

В недрах специалистов по вычислительной математике растет недовольство существующими порядками вычислений с плавающей точкой.
Постепенно назревает революционная ситуация, вот уже и программные (pun not intended) документы появляются (презентация 1.5 часа).

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

Интересно, кто и когда сделает первый коммерческий процессор, реализующий эту арифметику вместо (или наряду с) IEEE 754.

Даже если не понимать в деталях, посмотрите красивые картинки про погрешность операций, начиная со стр. 31 слайдов.

Развлекайтесь!

Comments

[sab123]

Иисус Мария, не получается! В его первом примере у меня Перл правильно вычисляет 2.

[spamsink]

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

[sab123]

perl -e 'print 3.2e7*4.0e7 + 1*1 + (–1)*(-1) + 8.0e7*(–1.6e7)'
perl -e '$a =3.2e7*4.0e7 ; +$b =1.*1.; $c = (-1.)*(-1.); $d = 8.0e7*(-1.6e7); $x = $a + $b; $x = $x + $c; $x = $x + $d; print $x'

Впрочем, будучи записано на Си через float действительно получается 0. Через double - уже правильно 2. Причем я не поленился заставить его сложить значение в память, чтоб оно урезалось до 64 бит:

#define FTYPE double

FTYPE sum(FTYPE a, FTYPE b, FTYPE c, FTYPE d);
FTYPE sum2(FTYPE a, FTYPE b);

main()
{
  FTYPE a = 3.2e7*4.0e7;
  FTYPE b = 1.*1.;
  FTYPE c = (-1.)*(-1.); 
  FTYPE d = 8.0e7*(-1.6e7);

  printf("%f\n", sum(a, b, c, d));
}

FTYPE sum(FTYPE a, FTYPE b, FTYPE c, FTYPE d)
{
    return sum2(sum2(sum2(a, b), c), d);
}

FTYPE sum2(FTYPE a, FTYPE b)
{
    volatile FTYPE r =  a + b;
    printf("&r=%p\n", &r);
    return r;
}

Переупорядочивание чтоб оно шло от меньшего по модулю к большему b+c+a+d ничего не поменяло.

[spamsink]

Наверное, в слайдах всё-таки ошибка. В 64-битном режиме должно всегда работать, потому что 10^14 - это всего 43 бита мантиссы, а в double - 54 бита.

[sab123]

Я тут задумался: если у нас есть разные по знаку числа, не будет ли более правильным другой порядок сложения? В частности, наоборот, от большего модуля к меньшему? Но это, конечно, тоже чревато последствиями. Если очень хотеть упираться, то можно наверное сделать так: отсортировать по модулю и вычислить результаты сложения всех пар соседних чисел. Выбрать из этих результатов самый маленький по модулю, убрать составляющие его числа, вставить результат на правильное место в сортировке (если он ноль, то не вставлять). Повторять пока не останется одно число. В виде попытки оптимизации можно складывать не все пары, а только те, внутри которых меняется знак, или которые два самых маленьких числа в последовательности одного знака. С другой стороны, просто сложить все подряд возможно окажется быстрее.

[pigdeon.livejournal.com]

Предвижу отсутствие энтузиазма у разработчиков железа. Данный формат представления вещественных чисел является метаформатом, который выглядит красиво только при хранении. Реальные вычисления производятся сейчас и скорее всего будут поизводиться в дальнейшем, с фиксированной разрядной сеткой, и сетка эта, для достижения заявленных характеристик, должна быть очень большой: 119 бит, как указано в презентации. Современные double вычисления производятся с внутренней 80 битовой мантиссой, из которой хранится 53 бита. Когда смогут задешево увеличить разрядность, то станут использовать точность в 128 бит. Борьба со служебными значениями (NaN) мне и вовсе непонятна: их существование обусловлено, конечно, исторически, но также дает информацию о том, что именно пошло "неправильно".

[spamsink]

Характеристики зависят от спецификации. Для нейронных сетей может хватить и 16 бит. Собственно, второй формат (posit) на особо длинные числа и не рассчитан.

Современные double вычисления производятся с внутренней 64-битной мантиссой, так что полноразрядное представление числа оказывается длиной 80 бит (long double), а слайд про 119 бит, которых хватает для получения такой точности, которая в IEEE достижима только на 256 битах - это просто выпендреж.

В реальной жизни ни inexact bit, предусмотренный в IEEE, не используется, ни значения информационного поля NaN (кроме, НЯМС, демонстрационных целей, как бы их можно было выпендриться используючи), а только флаг quiet/signaling NaN. Ну так в предлагаемой реализации NaN будет появляться реже, а когда будет, то будет всегда signaling.

[vak]

То есть уже имеем конкуренцию: posit супротив unum. Интересно будет посмотреть на реализацию.

[spamsink]

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

[juan_gandhi]

Ну слава те господи, движуха. А то позор же, сколько этому 754, 30 лет? Больше? Ассоциативности нет; коммутативности, наверно, тоже; что это за математика-то вообще. Четыре округления, две бесконечности, нерефлексивное равенство... Ужас.

[spamsink]

Ну слава те господи, движуха.

My thoughts exactly. ;)

[fatoff]

Лень глубоко вникать. Как мне непрофессионально кажется, в идеале носителями разрядов плавающей точки могут служить строки. И пусть себе плавают. Может, после просчитанных порядков ставить некоторый символ, вроде формулы вычисления далее идущих "вглубь" порядков.

[spamsink]

Есть https://en.wikipedia.org/wiki/GNU_MPFR но хочется-то компактного эффективного представления, чтобы операции за считаные такты выполнялись.