В интернете есть разные статьи на тему того, что для хранения строк в памяти можно использовать UTF-8, например: http://www.nubaria.com/en/blog/?p=289
Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>В интернете есть разные статьи на тему того, что для хранения строк в памяти можно использовать UTF-8, например: ЭФ>http://www.nubaria.com/en/blog/?p=289
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А зачем? Уменьшить объём занимаемой памяти и усложнить взаимодействие со строками? Вам не достаточно неоднозначности юникода?
Во-первых UTF-8 является обратно совместимым с ASCIIZ строками. Во-вторых алгоритмы UTF-8 очень быстрые и довольно простые для реализации, чего не скажешь об арифметическом кодировании.
Но в целом это может быть полезно в каких-то случаях. Кеши процессоров штука ценная. Было бы интересно взять какую-то сложную программу и попробовать поменять там кодирование строк и посмотреть на результаты.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А как по нём делать поиск или выделение подстроки?
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>> А как по нём делать поиск или выделение подстроки?
ЭФ>А с UTF-8 как? На нём же Кнут-Моррис-Пратт работать не должен.
Кнут-Морисс-Пратт ищет последовательность байтов внутри длинной последовательности байтов. Ему все равно, что некоторые символы занимают более одного байта. Ему только важно, что каждый символ кодируется однозначным образом.
Вот что реально в UTF работает плохо, это доступ к символам/подстрокам по номеру символа: надо сначала найти положение символа в строке. Но это не так уж часто бывает нужно, на самом деле.
Pzz>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>> и в UTF-8 это не так. Pzz> Каким образом?
Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
А если говорить "мы будем применять специальные приседания, такие как унификация при загрузке", то я начну говорить, что можно применять неадаптивного хаффмена.
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>>> и в UTF-8 это не так. Pzz>> Каким образом?
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Только это проблема не UTF-8, но в целом ты прав, да
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>>> и в UTF-8 это не так. Pzz>> Каким образом?
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Ну эта дурь да, присуща юникоду вообще. UTF-8 в этом вопросе ничего не меняет.
Вообще, это не такой уж и очевидный вопрос, считать эти строки одинаковыми, или не считать. От назначения сравнения, по-видимому, зависит.
ЭФ>А если говорить "мы будем применять специальные приседания, такие как унификация при загрузке", то я начну говорить, что можно применять неадаптивного хаффмена.
В твоем любимом хаффмане эта проблема никуда не денется
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А смысл? Строки нужны в коде как строки если они модифицируются и куда то выводятся/пишутся/пересылаются где они нужны именно в человекочитаемом виде.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Про нормализацию слышал?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Это совсем другая проблема, к обсуждаемому не имеющая отношения.
Кнут-Моррис-Пратт на UTF-8 придется модифицировать скорее всего достаточно будет небольшого усложнения.
Здравствуйте, CreatorCray, Вы писали:
ЭФ>>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например. CC>Про нормализацию слышал?
Так она может быть разной. Например, в строки с символами постоянной длины. Ну, раз уж все равно с этой нормализацией приседать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>То есть ты не возражаешь, что если хранить в памяти строки пожатые хаффменом,
Почему хаффманом? в UTF-8 с хаффманом только идея общая.
ЭФ>то тоже можно использовать для поиска модернизированный КМП ?
Если символы вписываются в границы байт, то усложнение небольшое, не вписываются как в полноценном хаффмане или тем более арифметическом кодировании, до замучаешься подстроку искать даже не КМП, а самым прямолинейным и топорным алгоритмом.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я же привёл выше ссылку на статью про то как модифицировали КМП под хаффмана.
Там только ссылки, причем на что-то печатное. Или я совсем не умею пользоваться подобными источниками.
Модифицировать конечно можно, но накладные расходы вырастут, а уж если хаффман будет не игрушечным (очень простым вариантом которого можно считать и 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-ами, которые на практике означают не пойми что.
