Комментарии 28
Что-то мне подсказывает, что если в тексте заглавных букв будет больше, то все поменяется наоборот и строчные будут "мешать". Кажется что проблема не в "регистре" символов, а в их статистическом распределении, в обычно тексте заглавных просто меньше и они проводят к "раздуваю" словаря.
Согласен - это слишком банальный опыт. Было бы интереснее сравнить с текстом набранным 100% заглавными, или тот же текст, но первые буквы строчные, а остальные заглавные - тогда бы можно было делать выводы, например, что из-за битового представления сжимаются лучше...
Вдобавок получить на 31 байт меньше на большой статье, без разбора где именно вышло сэкономить - попахивает неправдной. Современные архиваторы со словарями вполне могли бы тот же Sat сжать внутренним словарем, где уверен дни недели и так есть как часто встречающиеся сочетания..
статья о том, почему больший словарь занимает больше места, чем меньший словарь.
Было бы любопытно посмотреть зависимость сжимаемости от регистра текста у brotli. Там ведь встроенный словарь, построенный с помощью анализа большого количества HTML/js/CSS, и насколько я понимаю, словарь этот case sensitive.
А разве код Хаффмана не в конце стоит? Почему в начале-то?
В принципе, в английских заголовках вообще не нужны заглавные буквы, их легко закапитализировать с помощью text-transform: capitalize. А вот что касается остального текста, интересная задача, насколько сложно, используя словари или AI, восстановить капитализацию слов, если весь текст передан в lowercase
В бывают заглавные буквы не после точек? Ну т.е. можно декапитализировать только первые буквы и буквы после точек, точек с пробелами, возвратами кареток итп. И аи не понадобится... А с помощью нейросети, возможно удастся просто выкинуть половину букв, а потом восстановить. Но это не точно :).
В английских заголовках заглавные буквы почти после всего
Вот это кстати любопытная идея, которая правда очень похожа на сжатие с использованием словаря, только вместо словаря какой нибудь gptChat. Мы сначала выкидываем две трети букв и даём ему задачу восстановить текст (ну или для начала только согласные уберём), дальше сравниваем результат, если 100% совпало - отдаём, если есть ошибки - увеличиваем там количество букв и повторяем). Каждую страницу придётся "запекать" заранее, а у каждого пользователя должен быть одинаковый набор весов, но мне кажется план рабочий). А если уж потом хаффманом жахнуть с укороченным словарём и lzss накрыть - вообще хорошо будет ?
А потом модель gptChat дообучили и она перестала выдавать 100% результат.
Интуитивно кажется, что если как-то знаки препинания удалить, то многие слова превратятся в пары слов итп. Ну т.е. можно будет какой-то словарь сделать заранее по которому все будет сжиматься чуть ли не предложениями. Вообще для текста, наверное, проще нейросеть тренировать в сторону добавления воды :). Ну т.е. присылать и хранить сразу "автореферат", а обмазать его мычанием и бурчанием нейросеть, наверное сможет и сама. Потом пять раз своими словами описать итд итп. И получится статья для газеты. А в сжатом виде 2-3 предложения.
Имена, названия, аббревиатуры. Местоимение «I». Местоимение «Вы» в единственном числе.
Зачем экономить углекислый газ?
Получается, в коде выгоднее использовать underscore_notation вместо CamelCase. А лучше вообще использовать имена из одного-двух символов и повторно использовать переменные - подумайте об экологии!
а если вместо разных букв использовать только одну, но сжиматься будет еще лучше.
Разве baobaba не должна сжаться до bao<3,2><5,2> ?
Почему текст в нижнем регистре сжимается лучше