спасение утопающих
Jun. 25th, 2011 11:07 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80Подробный список известных вариантов хранения с плавающей точкой на всех известных архитектурах - просто доставляет разнообразием и хитрыми решениями.
Несмотря на это, всё равно придётся делать своё - потому что должно тривиально читаться в hex-дампе.
(И вообще автор жжот нипадецки - но оценить его могут только те, кто работал с битово-ассемблерными потрохами минимум двух заметно разных рахитектур...)
Несмотря на это, всё равно придётся делать своё - потому что должно тривиально читаться в hex-дампе.
(И вообще автор жжот нипадецки - но оценить его могут только те, кто работал с битово-ассемблерными потрохами минимум двух заметно разных рахитектур...)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-06-25 08:23 am (UTC)no subject
Date: 2011-06-25 08:25 am (UTC)no subject
Date: 2011-06-25 09:00 am (UTC)Кроме того, даже в TLV плавающая точка в ASN.1 кодируется очень компактно. Например, кодирование нуля занимает ноль байт V (то есть, без учёта двух байта на T и V). Кодирование маленьких чисел тоже экономнее, чем больших.
no subject
Date: 2011-06-25 09:26 am (UTC)1) фиксированный размер представления (4 байта)
2) фиксированный формат
3) отсутствие лишних указателей типа "а тут у нас float"
4) чтобы легко воспринималось глазами в потоке - например "это +20"
no subject
Date: 2011-06-25 09:49 am (UTC)По-моему, пункты 1 и 4 противоречат друг другу.
no subject
Date: 2011-06-25 12:11 pm (UTC)- по смещению 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" нам таки доступно. :)
no subject
Date: 2011-06-25 07:21 pm (UTC)На самом деле, основание 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, мантисса).
no subject
Date: 2011-06-25 07:27 pm (UTC)В моём случае таки проще читать. Можешь считать местной спецификой;)
Про основание порядка - ok, согласен, сделаем двоичным.
float32 (точнее, binary32 имени IEEE754) мне не нравится именно принудительной нормализацией к верхним значениям.
no subject
Date: 2011-06-25 07:51 pm (UTC)Кстати, нормализация — это процесс, никто же не заставляет его делать тебе. Просто формат у него можно взять и всё.
Зато можно будет прямо во float кастить и получать вменяемые результаты.
no subject
Date: 2011-06-25 08:00 pm (UTC)Заставляет, если как в IEEE754 при biased_exponent != 0 старший бит мантиссы всегда 1 и скрыт.
no subject
Date: 2011-06-25 08:12 pm (UTC)no subject
Date: 2011-06-25 09:18 am (UTC)А зачем своё? Для hex-дампа есть %a. ;)
no subject
Date: 2011-06-25 09:24 am (UTC)При передаче, например, в IEEE754 такой лёгкости нет.
no subject
Date: 2011-06-25 09:50 am (UTC)no subject
Date: 2011-06-25 09:09 pm (UTC)Лучше уж специальный декодер приспособить, который не только hex-дам кажет, но и из флоата декодирует. Или в тексте, в десятичном виде — куда читаемее.
no subject
Date: 2011-06-25 06:27 pm (UTC)no subject
Date: 2011-06-25 11:32 pm (UTC)http://erlang.org/pipermail/erlang-bugs/2011-June/002486.html
Какое же всё-таки это дерьмо, этот ваш ASN.1...
no subject
Date: 2011-06-26 07:09 am (UTC)