Здравствуйте, pagid, Вы писали:

_>>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
P>Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.
Основной посыл не в скорости вычислений, а в скорости пересылки данных. Сжатие — основной посыл и гамма коды тут очень хорошо вписались.

P>О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?
Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты.
Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает. Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему.

_>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
P>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов.

_>>Для более точных моделей ничто не мешает использовать большую точность.
P>64-разрядный IEEE-754
Не 64бит, а значительно больше.
P>Но ради чего пыжились придумывая как скрестить ужа с ежом?
Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне.

_>>И потом тут как всегда компромис: вам надо точно или быстро.
P>Так все же насколько быстрее?
В 2 раза быстрее по памяти если использовать вместо double.
Зачем по вашему float16 используют?
В некоторых задачах снижают точность ниже плинтуса https://www.sysml.cc/doc/2019/168.pdf и работает

Здравствуйте, qwertyuiop, Вы писали:

Q>Здравствуйте, LaptevVV, Вы писали:

Q>IEEE-754, конечно, уродство ещё то, но я не вижу чем новый формат лучше. Один только отдельный бит знака сводит на нет преимущества нового формата. И как при наличии этого бита он может избежать такой странности, как несовпадающие значения 0 и -0? Not-a-number (NaN), так же как и бесконечности (причём разных знаков) — тоже полезны как результат выполнения функций в которые передаётся недопустимый аргумент. А разная длина мантиссы у разных порядков даже вредна, при этом теряется сам смысл плавающей точки.
Нет там +0 и -0 и +inf и -inf там есть только 0 и ComplexInfinity

Posit6

Здравствуйте, kov_serg, Вы писали:

_>Основной посыл не в скорости вычислений, а в скорости пересылки данных.
Зачем она? Скорость вычислений понятно. И да скорость вычислений это интегральный показатель, необходимое время для пересылки память-кэш и кэш-процессор она разумеется тоже должа учитывать. Или о какой пересылке речь, по каким-то каналам связи что ли?

_>Сжатие — основной посыл и гамма коды тут очень хорошо вписались.
Как хорошо? Есть какие-то оценки?
Хотя стоп-стоп, я же для начала попросил сравнить скорость работы существующих реализаций float и double (в С-шной терминологии), это позволило бы для начала понять, а нужно ли вообще задумываться над желанием запихнуть в 32-разряда что-то большее, чем сейчас чуток приближающее к double.

_>Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты.
То есть подогнать тип "впритирочку". А потом при чуть других данных окажется, что из этой притирочки результат, более вероятно промежуточный, выходит. И кто тогда и сразу ли, и по какой причине поймет, что в результате получилась лажа?

_>Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает.
Но сначала нужен ответ на вопрос — с какой целью?

_>Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему.
И какие реальные проблемы решит? Иррациональный страх недоучек-хипстеров от недопонимаемого ими формата с плавающей точкой? Нет, не решит, пока это именно плавающая точка никаких реальных проблем и необходимости понимать её особенности подобная перестановка кроватей не разрешит.


_>>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
P>>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом.
Так хватит или не хватит?

_>Не 64бит, а значительно больше.
Зачем и для чего больше?

_>Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне.
Если сравнивать posit32 и double, то потеряв очень много значащих цифр. Но если ты готов вести инженерные расчеты с четырьмя значащими цифрами, то чем плох сегодняшний float? там там их больше.

_>В 2 раза быстрее по памяти если использовать вместо double.
При чем тут память? И не заменяют эти posit32 double, по этой причине говорить даже о двукратной экономии памяти (таки с какой целью? ) это лукавство.

Здравствуйте, pagid, Вы писали:

_>>Основной посыл не в скорости вычислений, а в скорости пересылки данных.
P>Зачем она? Скорость вычислений понятно. И да скорость вычислений это интегральный показатель, необходимое время для пересылки память-кэш и кэш-процессор она разумеется тоже должа учитывать. Или о какой пересылке речь, по каким-то каналам связи что ли?
Очень просто передача между CPU и GPU

_>>Сжатие — основной посыл и гамма коды тут очень хорошо вписались.
P>Как хорошо? Есть какие-то оценки?
P>Хотя стоп-стоп, я же для начала попросил сравнить скорость работы существующих реализаций float и double (в С-шной терминологии), это позволило бы для начала понять, а нужно ли вообще задумываться над желанием запихнуть в 32-разряда что-то большее, чем сейчас чуток приближающее к double.
Скороть работы можно сравнить только на конкретных задачах. Так как тут всё сильно зависит от реализации.

	например
	!! Люто синтетический подгоночный тест: #include <time.h> #include <stdio.h> #include <stdlib.h> #include <string.h> template<class T> void fn(int n,T *x,T q) { for(int j=0,i=2;i<n;i+=2) { x[i ]=x[i-2]*(1-q)-x[j+1]*q; x[i+1]=x[i-1]*(1-q)+x[j]*q; j+=2*(i>>5); if (j>i) j-=i; // давим кэш } } template<class T> double test(int n,int m) { clock_t t1,t2; T *x=new T[n]; memset(x,0,sizeof(T)*n); x[0]=1; x[1]=0; t1=clock(); for(int i=0;i<m;++i) fn<T>(n,x,1e-6); t2=clock(); //printf("%7.4f %7.4f ",x[n-2],x[n-1]); delete[] x; double sz=sizeof(T)*n/1024.0/1024, dt=(double)(t2-t1)/CLOCKS_PER_SEC; double rate=m*sz/dt, crate=rate/sizeof(T); printf("dt=%.2fsec data_size=%5.1fMb data_rate=%.1fMb/s" " compute_rate=%.1fM/s\n",dt,sz,rate,crate); return crate; } int main(int argc, char **argv) { enum { n=10000000,m=100 }; double rf=test<float>(n,m), rd=test<double>(n,m); printf("float/double=%.2f\n",rf/rd); return 0; } g++ test.cpp -O3 && ./a.out dt=2.30sec data_size= 38.1Mb data_rate=1655.5Mb/s compute_rate=413.9M/s dt=4.80sec data_size= 76.3Mb data_rate=1589.5Mb/s compute_rate=198.7M/s float/double=2.08

_>>Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты.
P>То есть подогнать тип "впритирочку". А потом при чуть других данных окажется, что из этой притирочки результат, более вероятно промежуточный, выходит. И кто тогда и сразу ли, и по какой причине поймет, что в результате получилась лажа?
Если модель лажа, то никакие типы данных не помогут.

_>>Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает.
P>Но сначала нужен ответ на вопрос — с какой целью?

_>>Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему.
P>И какие реальные проблемы решит?
Это позволяет иметь более простую реализацию.
P>Иррациональный страх недоучек-хипстеров от недопонимаемого ими формата с плавающей точкой? Нет, не решит, пока это именно плавающая точка никаких реальных проблем и необходимости понимать её особенности подобная перестановка кроватей не разрешит.
o_O? Использование сжатия данных это один из путей которыми придётся увеличивать произвоительность. Т.к. ныче память это медленно.

P>>>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом.
P>Так хватит или не хватит?
В многих задачах вполне приемлемо. Но если не критично люди не заморачиваются и используют double. Т.к. в обычных вычислениях кэш процессора нивилирует отличия по времени доступа в ram.

_>>Не 64бит, а значительно больше.
P>Зачем и для чего больше?
Орбиты небесных тел считать или жесткие системы уравнений.

_>>Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне.
P>Если сравнивать posit32 и double, то потеряв очень много значащих цифр. Но если ты готов вести инженерные расчеты с четырьмя значащими цифрами, то чем плох сегодняшний float? там там их больше.
Он не плох для определённого круга задач вполне приемлем.
Сценарий такой ведёте расчеты в double в double80 (fpu) или в double128, а результаты вычислений для передачи упаковываете в posit.

_>>В 2 раза быстрее по памяти если использовать вместо double.
P>При чем тут память? И не заменяют эти posit32 double, по этой причине говорить даже о двукратной экономии памяти (таки с какой целью? ) это лукавство.
Для расчетов можно и fixed32 использовать, но у него динамический диапазон очень маленький и надо за ним очень внимательно следить. В posit32 в overflow и underflow будет тяжелее уйти.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, pagid, Вы писали:

_>Очень просто передача между CPU и GPU
Совсем не в теме про расчете на GPU. С какой точностью там принято считать с плавающей точкой?


_>Скороть работы можно сравнить только на конкретных задачах. Так как тут всё сильно зависит от реализации.
_>например
_>!! Люто синтетический подгоночный тест:
_>[cpp]
...
...
...
_>g++ test.cpp -O3 && ./a.out
_>dt=2.30sec data_size= 38.1Mb data_rate=1655.5Mb/s compute_rate=413.9M/s
_>dt=4.80sec data_size= 76.3Mb data_rate=1589.5Mb/s compute_rate=198.7M/s
_>float/double=2.08


MSVC, старенький 10-й

x86
dt=2.44sec data_size= 38.1Mb data_rate=1564.7Mb/s compute_rate=391.2M/s
dt=3.19sec data_size= 76.3Mb data_rate=2393.9Mb/s compute_rate=299.2M/s
float/double=1.31

x64
dt=2.30sec data_size= 38.1Mb data_rate=1660.7Mb/s compute_rate=415.2M/s
dt=3.19sec data_size= 76.3Mb data_rate=2393.2Mb/s compute_rate=299.1M/s
float/double=1.39

Намного лучше, чем я предполагал. Считал, что как раз около двух раз это как раз вполне реально.

_>Если модель лажа, то никакие типы данных не помогут.
Не, так не пойдет. Это слишком общая сентенция. Потеря же точности при недостаточной длине в представлении числа объективная реальность. Разумеется от алгоритма и его реализации зависит, при уменьшении количества значащих цифр оно неизбежно.
_>Для расчетов можно и fixed32 использовать, но у него динамический диапазон очень маленький и надо за ним очень внимательно следить. В posit32 в overflow и underflow будет тяжелее уйти.
Не, это тоже из какого-то другого разговора.

Здравствуйте, pagid, Вы писали:

P>float/double=1.39
P>Намного лучше, чем я предполагал. Считал, что как раз около двух раз это как раз вполне реально.
Занятно. У меня на i7-4770/DDR3 стабильно получается 1.8-1.9. А на i5-7300HQ/DDR4 получается тоже в районе 1.45 (с похожими абсолютными цифрами). Один раз вышло 1.3, но это обновления в фоне ставились.

MA> Занятно. У меня на i7-4770/DDR3 стабильно получается 1.8-1.9. А на i5-7300HQ/DDR4 получается тоже в районе 1.45 (с похожими абсолютными цифрами).
MA>Один раз вышло 1.3, но это обновления в фоне ставились.

i5-6400 память Х.З. какая
Повторяется. Если тест 64-разрядный от 1.38 до 1.55, если 32-разрядный 1.32 — 1.34 при этом абсолютные цифры немного лучше.

На стареньком AMD процессоре абсолютные цифры в несколько раз больше, но соотношение примерно такое же. Там память DDR3

Здравствуйте, LaptevVV, Вы писали:

LVV>https://habr.com/ru/post/462385/
LVV>Грядет замена стандарта IEEE-754?
LVV>https://wiki2.org/en/Unum_(number_format)
LVV>Там много ссылок.

C++ астрологи объявят неделю тайпдефов и макросов, не иначе

MD>C++ астрологи объявят неделю тайпдефов и макросов, не иначе
А КТО ТАКИЕ с++ АСТРОЛОГИ?
Кого ты к ним относишь?

Здравствуйте, kov_serg, Вы писали:

N>>Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты.
_>Нет дело не в стандартах.

Очень аргументированное утверждение

_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.

Нормальные там погрешности, многие вещи меряют с точностью до 5-6 десятичного знака, а то и точнее. Это не XIX век.

_>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) — наименьше по модулю представимое не нулевое число

Я не смог однозначно понять, что эти "режимы" значат. В оригинальной pdfʼке автор разве что качучу вприсядку не танцует — стиль такой, что туда вставить пару десятков одесских анекдотов вообще ничего не изменит; но понять оттуда, чему равно в его предложениях, например, es для 32-битного числа — я тупо ниасилил. Если вы осилили, чему там предлагается сделать равным это es? И значит ли "режим N" в вашей таблице, что в числе ровно N так называемых regime bits?

Если "да" на последнее, то в диапазоне порядков до 3.4e+38 — то, что позволяет float32 — точность уже в разы хуже.

_>[/code]
_>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32

N>>Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями.
_>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.

"Обычные инженерные" это то, для чего использовались таблицы Брадиса? (У меня других ассоциаций на 4 значащих цифры нет, поэтому предполагаю источник отсюда.) А чего вдруг такая подмена контекста? Разве float32 предполагался для "обычных инженерных расчётов" образца 1921 года?

_> Для более точных моделей ничто не мешает использовать большую точность.
_>Более того есть методы позволяющие уточнять результат имея ограниченную точность вычислений.
_>И потом тут как всегда компромис: вам надо точно или быстро.

У меня такой же компромисс есть с IEEE754, причём там нужно следить за сильно меньшим набором факторов.
Например, там есть явный контроль переполнений и недополнений.
А тут — будет, например, параметр режима вычислений "поднимать флаг, если точность стала менее 16 бит"?
И так для каждого значения с шагом хотя бы 4 бита?

Здравствуйте, pagid, Вы писали:

P>Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.

Если реализация не явно урезана (по историческим причинам или от недостатка ресурсов), то:
— Сложение, вычитание, сравнение — времена равны (основные сложности всё равно идут не по длине).
— Умножение — ну процентов 10-20 разницы.
— Деление, квадратный корень — тут уже начинает сильно зависеть от алгоритма, но в общем в полтора раза.

Трансцедентные функции могут разниться сильно больше — например, на float32 хватит 3 членов ряда, а на 64 нужно уже 7, и все вычислять большей длиной... — может быть в 3-5 раз.

_>>режим 9 — до 1.34e+154 3.6 значащих цифр во float не представима
_>>режим 13 — до 1e+2466 1.2 значащая цифра во float не представима
_>>...

P>О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?

Я там спросил, но предполагаю, что речь идёт о длине поля regime bits (что задаёт смещение порядка и длину мантиссы). Тогда выбирать ничего не надо. Но кто знает... читать "спеку" от автора сложно — смешуёчков и дифирамбов больше, чем сути. Боюсь, одно это отвратит толковых читателей.

_>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
P>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов.
_>>Для более точных моделей ничто не мешает использовать большую точность.
P>64-разрядный IEEE-754
P>Но ради чего пыжились придумывая как скрестить ужа с ежом?

+1.

_>>И потом тут как всегда компромис: вам надо точно или быстро.
P>Так все же насколько быстрее?

Для этого надо подождать и затем измерить образцовую софтовую реализацию в стиле berkeley-softfloat.
Я однако предполагаю, что с таким стилем мы этого не дождёмся...

Здравствуйте, pagid, Вы писали:

P>Здравствуйте, kov_serg, Вы писали:

_>>Здравствуйте, pagid, Вы писали:

_>>Очень просто передача между CPU и GPU
P>Совсем не в теме про расчете на GPU. С какой точностью там принято считать с плавающей точкой?

Долго было только 32 бита. Сейчас массово добавлены 64 и местами 16.

Здравствуйте, netch80, Вы писали:

N>Я не смог однозначно понять, что эти "режимы" значат. В оригинальной pdfʼке автор разве что качучу вприсядку не танцует — стиль такой, что туда вставить пару десятков одесских анекдотов вообще ничего не изменит; но понять оттуда, чему равно в его предложениях, например, es для 32-битного числа — я тупо ниасилил. Если вы осилили, чему там предлагается сделать равным это es? И значит ли "режим N" в вашей таблице, что в числе ровно N так называемых regime bits?
Я взял es=2 для определенности.

У поситов есть еще интересное свойство

int32 px=posit32(x), py=posit32(y)
если px<py => x<y

если px==-px то это или 0 или inf
если px==0          => x=0
если px==0x80000000 => x=inf

Здравствуйте, LaptevVV, Вы писали:

MD>>C++ астрологи объявят неделю тайпдефов и макросов, не иначе
LVV>А КТО ТАКИЕ с++ АСТРОЛОГИ?
LVV>Кого ты к ним относишь?

Это мемчик из Героев Меча и Магии. Там в некоторые дни выскакивало сообщение "Астрологи объявили неделю X, количество Y увеличено вдвое"