LINUX.ORG.RU
решено Форум — Development  

достаточно ли места в NaN floats(каких) для utf?

 


0

2

достаточно ли места в NaN(и в целом в symbols) floats(каких) для utf?

ну и лаконичнейшие алго для сериализации и обратно

[мало телепатов далеки они]:

нужно смешать флоаты и utf

флоаты остаются флоатами а utf помещается в ненормальные NaN и прочие inf

достаточно ли и когда места для этого

настоящие числа только в эталоном ввиде если нет значит это сериализованая utf

вот!

[ps] в некотором приблежение есть ли место «между струйками» что бы застегонографить utf в не real числа

★☆

Последнее исправление: qulinxao3 (всего исправлений: 2)
← Не распознается текст капчи переменной длины
Луговский 20 лет спустя →
Ответ на: комментарий от soomrack

Речь же про сериализацию. Я так понимаю ТС хочет записывать многобайтный utf как float потому что в кофеварке нет поддержки utf для символов. Загружать в FPU он их наверное не будет.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

есть поток нормализованных флоатов(все реальные числа без символов и исключений и прочих Nan inf -0) с разбрызгаными коментариями(текста) между

есть ли место и при каком размере float Для помещения в «нереальные»(ну или не нормализованные если совсем места в нереальных нет)

т.е семантика - если флоат ненормализован - это сериализованый кусок utf

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от qulinxao3

В любом случае, лучше передовать тип unsigned int (и его варианты), а потом их интерпретировать как float или wchat или еще как-то. Если ты будешь пытаться интерпретировать именно float как нечто иное, то будь готов к тому, что они могут незначительно (для float) измениться.

soomrack ★★★★★
() 
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <math.h>

struct __attribute__((packed)) float_t 
{
    unsigned sign : 1;
    unsigned frac :  23;
    unsigned exp : 8;
};

int main() 
{
    struct float_t f;
    float fx;
    f.sign = 1;
    f.exp = 127;
    f.frac = 6291456;
    for (int i = 0; i <= UCHAR_MAX; ++i) {
        f.frac = 6291456 + i;
        memcpy(&fx, &f, sizeof(float));
        if (!isnan(fx)) {
            printf("не хватает\n");
            return 1;
        }
        memcpy(&f, &fx, sizeof(float));
        if (f.frac - 6291456 != i) {
            printf("не хватает\n");
            return 1;
        }
    }
    printf("хватает\n");
}
MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)

NAN это значение где в поле порядка все единицы, остаются поле мантиссы и знака. В флоате 23 бита по мантиссу (картинка), из них одно значение (все нули) для бесконечности, остальные можешь использовать как хочешь. Ну и ещё 1 бит знака. Для представления юникодных символов в норме достаточно 16 бит, если во всяким мусором из недефолтных сегментов (смайлики итд) то 21 бит.

Страшилки про «точностью до бита» можно не слушать, пока ты не попытаешься эти nan-ы сунуть в математические вычисления они никуда не превратятся.

Но ты занимаешься какой-то ерундой.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от soomrack

Только хранить там символы не стоит, т.к. для float отдельная логика в процессоре

Как минимум деление общее для float и integer у intel.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от firkax

Для представления юникодных символов в норме достаточно 16 бит, если во всяким мусором из недефолтных сегментов (смайлики итд) то 21 бит.

Если нормально поддерживать UTF-8, то до 4 байтов по стандарту.

anonymous
()
Ответ на: комментарий от anonymous

Нет, юникодные коды от 0 до 0x10FFFF (что за одарённые личности решили вместо 0xFFFFF сделать 0x10FFFF и потратить ещё целый бит и целый hex-знак на почти ничего - отдельный вопрос). UTF-8 это всего лишь их кодирование в 8-бит ascii-совместимый вид. Если не пользоваться невалидными последовательностями (на которых utf-8 парсер всё равно будет падать) то всё влезает в 21 бит.

firkax ★★★★★
()

флоаты остаются флоатами а utf помещается в ненормальные NaN и прочие inf

достаточно ли и когда места для этого

Вполне, даже в 32-битном IEEE754 числе одинарной точности. NaN - это число, у которого экспонента - это все единицы, а мантисса не равна нулю. Мантисса в float содержит 24 бита. Юникод использует номера code points от 0 до 0x10ffff включительно, что влезает в 21 бит. Смело кладите номера code points в мантиссу NaN’а, только представление для нулевого символа (U+0000) какое-то другое придумайте. Будет как UTF-32, но более дебильно.

AITap ★★★★★
()

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

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

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от firkax

Но ты занимаешься какой-то ерундой.

Устроить утечку конфиденциальных данных через какой-нибудь мониторинг заряда батарейки это совсем не ерунда.

anonymous
()

Снимаю шляпу перед всеми отозвавшимися - лично я далеко не сразу смог распарсить этот поток сознания, а в оригинальной редакции - так вообще не :)

bugfixer ★★★★★
()

нужно смешать флоаты и utf

Братан, это всегда так начинается, "Коктейль!", "Коктейль!". А на утро ты в обезьяннике будешь в протоколе объяснительную писать.

Запомни золотое правило - НЕ СМЕШИВАЙ!!111

LamerOk ★★★★★
()

UTF – это разные кодировки Юникода. Есть UTF-8, 16, UCS-2 и так далее. Сам unicode code point при этом помещается в 32 битное целое. С помощью кодировки он может быть представлен по разному. Но при раскодировании превратится в 32 бита.

thegoldone ★★
()
← Не распознается текст капчи переменной длины
Development
Луговский 20 лет спустя →