- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
по поводу кодирования n-грамами (буквеными).
Не все так просто, ...
Лично я не могу сказать - просто или непросто - пока не узнаю, что понимается под "распакованым видом"?
да я был немножечко неточен: распакованный вид это все словоформы в однобайтовой кодировке. вот сейчас посмотрел 8.8 мегабайт. еще раз посчитал количество способов генерации словоформ в russian.aff (для испелл) 26 штук.
Если есть 100 тысяч слов-основ или их аналогов, то в среднем по словам Артизана, приходится 3 байта = 24 бит на одну словооснову вместе со способом генерации конечных словофрм. Последнее сожрет 4-5 бит. Итого на кодирование одной слово-основы можно потратить 21 бит. Словооснова в словаре имеет среднюю длину 8 байт. Если каким-нибудь хаффманом закодировать буквы, то в среднем на букву можно затратить бита 4. При этим если сгруппировать слова по первым 3-4 буквам, на каждое слово мы потратим в среднем 4 x 4 бита на кодирование окончания и еще нужно бит 8 - десять на кодирование смещения (если структура дерево). Итого в 21 бит мы никак не укладываемся, хотя получается что-то близкое к 300 килобайтам. Ну может не 300, но 400-500 возможно. Без экспериментов точно не скажешь. Тем не менее, я думаю, что Яндекса алгоритмы попроще были, но и размер словаря был поменьше 30-50 тысяч словоформ.
А что Вы понимаете под н-граммным кодированием?
- извините, а что такое "распакованный вид"? Это когда каждый символ занимает 8 бит? Или - как в Юникоде - 16 бит?
А букв в русском алфавите 33, то есть кодируются они 5 (с небольшим хвостиком) битами ...
На самом деле, я думаю, что Artisan так много туману напускает - по поводу кодирования n-грамами (буквеными).
Кстати, еще раз повторюсь буквы в русском языке кодируются где-то четырьмя битами в среднем, если использовать Хаффмана.
ребята, давайте жить дружно, еще раз повторюсь, в первоначальной постановке вопроса речь шла о загрузке словаря в ОЗУ, я со совей колокольни, не вижу смысла загружать в ОЗУ запакованные данные, и по прежнему думаю что все упирается в алгоритм формирования слов из некоего абстрактного списка основ, то что я вижу на данный момент лишь подтверждает мою уверенность в том что эти данные можно втиснуть в пресловутые 300Кб
Сейчас смысла в этом нет, а раньше, когда было 640 кб озу был/
ребята, давайте жить дружно, еще раз повторюсь, в первоначальной постановке вопроса речь шла о загрузке словаря в ОЗУ, я со совей колокольни, не вижу смысла загружать в ОЗУ запакованные данные, и по прежнему думаю что все упирается в алгоритм формирования слов из некоего абстрактного списка основ, то что я вижу на данный момент лишь подтверждает мою уверенность в том что эти данные можно втиснуть в пресловутые 300Кб
распакованный вид это все словоформы в однобайтовой кодировке. вот сейчас посмотрел 8.8 мегабайт. еще раз посчитал количество способов генерации словоформ в russian.aff (для испелл) 26 штук. Ну может не 300, но 400-500 возможно. Без экспериментов точно не скажешь.
Паковать надо совсем не так, ...
Ну, в общем-то, неважно цифра, как ни странно, получается похожая. Думаю, что с учетом того насколько это было давно точных цифры уже никто не помнит, поэтому +-30-40 процентов вполне допустимые отклонения.
Сейчас смысла в этом нет, а раньше, когда было 640 кб озу был/
но речь то идет именно о сейчас, не о вчера и не о завтра, к тому же вчера считался каждый байт ОЗУ и грузит туда лишние данные было просто глупостью, поэтому даже с оглядкой на вчера я остаюсь при своем мнение, запакованным данным нечего делать в ОЗУ, загрузив туда запакованные данные вам также надо будет загрузить и алгоритм компресии/декомпресии или юзать его с жесткого диска, ваш выигрыш в производительности и в том и в ином случае стремится к нулю
Паковать надо совсем не так, ...
еще раз повторюсь, ПОЖАЛУЙСТА, не можете обосновать свои слова, не бросайтесь ими
цифра, как ни странно, получается похожая.
Почему как ни странно? Если количество информации
одинаковое то и сжимать можно до одинакового размера
с поправкой на особенности алгоритмов, ...
Зодчий, ну какая-то безыдейная тема получилась. Понятно, что словарь сейчас паковать смысла нет, а вот, например, инвертированный индекс и, вообще, данные, не влезающие в память, есть. Посмотрите ссылочки на страничке
http://itman.narod.ru/articles/articles_ir.html#p5
но речь то идет именно о сейчас, не о вчера и не о завтра, к тому же вчера считался каждый байт ОЗУ и грузит туда лишние данные было просто глупостью, поэтому даже с оглядкой на вчера я остаюсь при своем мнение, запакованным данным нечего делать в ОЗУ, загрузив туда запакованные данные вам также надо будет загрузить и алгоритм компресии/декомпресии или юзать его с жесткого диска, ваш выигрыш в производительности и в том и в ином случае стремится к нулю
еще раз повторюсь, ПОЖАЛУЙСТА, не можете обосновать свои слова, не бросайтесь ими
Почему как ни странно? Если количество информации
одинаковое то и сжимать можно до одинакового размера
с поправкой на особенности алгоритмов, ...
Неожиданно большой коэффициент сжатия получается.