Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я же привёл выше ссылку на статью про то как модифицировали КМП под хаффмана.
Там только ссылки, причем на что-то печатное. Или я совсем не умею пользоваться подобными источниками.
Модифицировать конечно можно, но накладные расходы вырастут, а уж если хаффман будет не игрушечным (очень простым вариантом которого можно считать и utf-8), а адаптивным, то все еще усложнится, скорее всего до того, что текст проще будет вернуть в моноширокую кодировку. ЭФ>А мучаться я не буду, я буду "использовать библиотечные функции".
А мне показалось у тебя зреет желание модифицировать под арифметическое кодирование
P> А мне показалось у тебя зреет желание модифицировать под арифметическое кодирование
Тебе всё правильно показалось.
Только я этого вслух не говорю, потому что во мне есть неуверенность в том, что это в принципе возможно.
Потому что хаффман всё-таки проходит по границам битов, а арифметическое кодирование уже нет.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>В интернете есть разные статьи на тему того, что для хранения строк в памяти можно использовать UTF-8, например:
Можно, но не нужно.
С UTF-8 как сделать str.mid(10, 20) ?
Только сканирование с самого начала. Т.е. это O(n).
На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Строки должны работать быстро.
char16_t wcs[] = u"zß水🍌"; // !!!
Обычно utf-8 — это для хранения извне + передачи данных.
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
Архивировать, да. Но это если куда-то вовне выгружать.
Но сейчас ведь памяти много. Еще бы на строках экономить.
Здравствуйте, 3V, Вы писали:
3V>С UTF-8 как сделать str.mid(10, 20) ? 3V>Только сканирование с самого начала. Т.е. это O(n).
Если вы оперируете столь большими строками то можете позволить хранить и индексы для ускорения подобных операций.
Посмотрите на текстовые редакторы. Они не оперируют строкой.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1). 3V>Строки должны работать быстро. 3V>char16_t wcs[] = u"zß水🍌"; // !!!
unicode собака странная некоторые символы не символы, а модификаторы.
3V>Обычно utf-8 — это для хранения извне + передачи данных.
не для хранения и передачи есть zlib
3V>Архивировать, да. Но это если куда-то вовне выгружать. 3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
Памяти то много и она медленная
так что сжимать объекты уже пытались
Здравствуйте, 3V, Вы писали:
3V>С UTF-8 как сделать str.mid(10, 20) ? 3V>Только сканирование с самого начала. Т.е. это O(n). 3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1). 3V>Строки должны работать быстро. 3V>char16_t wcs[] = u"zß水🍌"; // !!!
Точно так же в UTF-16, UTF-32 требуется O(n).
Например символ Ä может быть представлен в виде двух символов A и умляут.
Чтобы понять , что это один символ , а не два нужно прочитать сначала строки.
А по факту как часто нужно делить строки на подстроки символом не входящим в ASCII?
Здравствуйте, 3V, Вы писали:
3V>Можно, но не нужно.
Очень даже нужно.
3V>С UTF-8 как сделать str.mid(10, 20) ? 3V>Только сканирование с самого начала. Т.е. это O(n).
Поэтому не нужно делать str.mid(10, 20), вот и всё.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Ты, видимо, не знаешь, как работает UTF-16, раз говоришь такое. На всякий случай проинформирую тебя: UTF-16 это кодировка с переменной длиной. Некоторые кодовые точки кодируются двумя байтами, некоторые четырьмя. Т.е. взяли худшие черты от UTF-8 и от UCS-32. И своим str.mid(10, 20) ты легко можешь разрезать какую-нибудь кодовую точку пополам и получить тарабарщину.
А не знаешь видимо потому, что привычные тебе символы кодируются двумя байтами. Но ты ничем не отличается от американцев, которым вообще плевать на кодировки, ведь всё влезает в 7 битов.
Не говоря уже о том, что многие глифы кодируются множеством кодовых точек. Разрезав UTF-32 строку ты её так же можешь испортить, если ты работаешь с реальным текстом, в котором, например, встречаются эмодзи, кодируемые несколькими кодовыми точками. Про всякие иероглифы говорить не буду, а вот эмодзи в 2020 году должны уже стать привычным атрибутом текста.
👱🏻♀️ этот эмодзи кодируется пятью кодовыми точками: U+1F471, U+1F3FB, U+200D, U+2640, U+FE0F. Порви его в середине и ты его испортишь.
3V>Строки должны работать быстро.
Произвольные выдуманные тобой операции — не должны. str.mid(10, 20), режущая строку по границам байтов как раз из таких операций. Смысла в ней немного.
3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.
Здравствуйте, vsb, Вы писали:
3V>>Строки должны работать быстро. vsb>Произвольные выдуманные тобой операции — не должны. str.mid(10, 20), режущая строку по границам байтов как раз из таких операций. Смысла в ней немного.
С чего это Mid() режет строки по байтам, да ещё и на границе? Это же строковая функция — она по определению умеет работать со строками, а не массивом raw-байтов.
3V>>Но сейчас ведь памяти много. Еще бы на строках экономить. vsb>В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.
А вот тут согласен
Здравствуйте, Rhino, Вы писали:
3V>>>Строки должны работать быстро. vsb>>Произвольные выдуманные тобой операции — не должны. str.mid(10, 20), режущая строку по границам байтов как раз из таких операций. Смысла в ней немного. R>С чего это Mid() режет строки по байтам, да ещё и на границе? Это же строковая функция — она по определению умеет работать со строками, а не массивом raw-байтов.
Не умеет. Она работает с т.н. char-ами, которые на практике означают не пойми что.
