спасение утопающих

[netch80]

Подробный список известных вариантов хранения с плавающей точкой на всех известных архитектурах - просто доставляет разнообразием и хитрыми решениями.

Несмотря на это, всё равно придётся делать своё - потому что должно тривиально читаться в hex-дампе.

(И вообще автор жжот нипадецки - но оценить его могут только те, кто работал с битово-ассемблерными потрохами минимум двух заметно разных рахитектур...)

Comments

[netch80.livejournal.com]

Что получилось:
- по смещению 0 - порядок, несмещённый (но см. ниже про позицию точки), в 2-complement, с основанием 16. То есть 0xFE значит "мантиссу разделить на 256", 0x01 - "мантиссу умножить на 16". Значение 0x80 выделено для спецсигналов типа "не смогли снять" (sNaN), "этого датчика вообще нет" (qNaN) и так далее.
- по смещениям 1-3 - мантисса, целое в 2-complement, точка в самом конце. Никакой нормализованности не требуется, агенты сбора данных не будут этим заниматься.
Например:
00 00 00 7F - значение +127
00 FF FF 81 - значение -127
FE 00 01 1C - значение 1.109 (такие идут, например, для VCore - они снимаются в сыром виде в 1/64 вольта, так что агент домножит на 4 и уложит в мантиссу, а порядок поставит в 0xFE)
80 01 00 00 - не удалось снять (signaling NaN, subvalue = 0)

и никакого противоречия.

На всякий случай уточню, что "вижу 7F и понимаю, что это 127" нам таки доступно. :)

[lionet.livejournal.com]

Поздравляю, ты придумал float32, который сложнее читать из-за 2-complement :)

На самом деле, основание 16 даёт больший range, но зато уменьшает precision с номинальных 23 бит до, в худшем случае, 19 бит. То есть, точность будет плавать где-то в районе 0.0002% (ошибка 0.0000019)
Не то чтобы это совсем плохо, но в float32:

1) знак виден сразу, ибо один бит на это выделен отдельно, а не сделана замесь в 2-complement.
2) отрицательные и положительные числа имеют одинаковый диапазон
3) отрицательные числа не сложнее воспринимать, чем положительные
5) мантисса имеет диапазон 2^-127..2^127, что исключительно прилично (подходит для всех измерений, кроме астрономических), а у тебя 16^-127..16^128, что непонятно зачем нужно. Для примера, 16^128 это "13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096", что совершенно дико и никогда не понадобиться вообще никому в мире в ближайший гугол лет. Лучше бы ты бит знака сделал в нулевом байте, чуть прижав диапазон экспоненты.

С другой стороны, бит знака + мантисса занимают девять бит, то есть, заезжают на первый байт. Но можно было бы их развернуть местами, тогда последний бит мантиссы был бы знаком, и всё.

Короче, можно лучше, и float32 — это почти идеальная вещь, только знак и экспоненту местами поменять: 8:1:23. Ну или в твоём формате, раз ты не гнушаешься прыжками точности мантиссы при переходе между разными значениями экспоненты, можно поприжать размер экспоненты и вынести знак и флаги в отдельные пару (четвёрку?) бит: 1:3:4:24 (знак-флаги-экспонента для b=16, мантисса).

[netch80.livejournal.com]

> Поздравляю, ты придумал float32, который сложнее читать из-за 2-complement :)

В моём случае таки проще читать. Можешь считать местной спецификой;)

Про основание порядка - ok, согласен, сделаем двоичным.

float32 (точнее, binary32 имени IEEE754) мне не нравится именно принудительной нормализацией к верхним значениям.

[lionet.livejournal.com]

Ну и то хлеб.

Кстати, нормализация — это процесс, никто же не заставляет его делать тебе. Просто формат у него можно взять и всё.

Зато можно будет прямо во float кастить и получать вменяемые результаты.

[netch80.livejournal.com]

> Кстати, нормализация — это процесс, никто же не заставляет его делать тебе.

Заставляет, если как в IEEE754 при biased_exponent != 0 старший бит мантиссы всегда 1 и скрыт.

[lionet.livejournal.com]

А, точно.