var bits = массив с фильтром
var buf = new Buffer(Object.keys(bits).length*4)
var j=0
for(var i in bits){
buf.writeInt32LE(bits[i],i*4)
}
fs.writeFileSync('test1.txt',s,{encoding:"ascii"});
Но на самом деле так места занимает больше из-за того, что бинарные данные почти не сжимаются.
Я это всё делал, но пришел к выводу, что большинство генерируемых слов – "псевдонеправильные". Ну невозможно описать правилами большинство неправильных слов типа "numismatograph" и "troid".
Забегая вперёд этой части статьи, скажу, что я пришел к выводу, что из-за того, что большая часть неправильных слов — псевдонеправильные(слова, не поддающиеся отсечению по правилам), единственный вариант решения- формальными правилами уменьшить словарь настолько, насколько это возможно, скормить его блуму или аналогу(если есть), а затем перед проверкой на блуме на входе по редким комбинациям отсекать "мусор".
Это моей было ключевой стратегией для уменьшения размера словаря – выделить слова, включающие в себя другие слова, и закодировать, сколько букв спереди или сзади можно отбросить для получения правильных слов.
Напишите обязательно! Я делал почти тоже самое, и тоже дошел до уменьшения слов до около 300К+ для скармливания их блуму, но так и не успел разобраться, как сохранить результат в <64k. В лучшем случае получал 120. Напишу об этом во второй части статьи.
SQL база у меня была локальная. Я хотел попробовать Azure ML, но споткнулся о существенную разницу в скорости выполнения запросов между азуровским и локальным SQL-серверами. В частности, создания таблицы с несуществующими четвёрками согласных, на азуре я так и не смог дождаться. Понимаю, что можно было поработать над оптимальностью запросов, но задача была другой.
Это мало, и это те же грабли, которые я опишу во второй части. Из-за того, что в реальных тестах много повторов, 65% на уникальных словах опустятся до 50%.
Да, только она сейчас неполная. Перед тем, как скармливать данные майнингу, я убрал из неё то, что отсекается описанными в этой статье простыми фильтрами. Сейчас в ней порядка 38М слов.
Технические статьи тоже будут. Полного раскрытия «внутренностей» я не сделаю, т.к. там есть несколько «ноу-хау» которые я не хотел бы выносить в паблик, но все этапы разработки «с нуля», включая выбор инструментария, постараюсь осветить. А вот насколько я в этом разбираюсь и насколько «грамотными» были мои решения – я и сам понятия не имею, т.к. ориентиров не было. Именно поэтому первая статья была именно о том, о чём она была. А вообще, кроме технического, оттенок в большинстве статей всё-таки будет ещё и эмоциональный, как и в этой статье, т.к. не имея опыта в этих технологиях и руководствуясь исключительно здравым смыслом в создании с нуля чего-то совершенно нового я постоянно находился (и нахожусь) в сомнениях относительно принятых как технических, так и стратегических решений. Я не верю, что подобные вопросы беспокоят только меня, поэтому решил не игнорировать эмоциональную часть этого процесса.
Но на самом деле так места занимает больше из-за того, что бинарные данные почти не сжимаются.
Я это всё делал, но пришел к выводу, что большинство генерируемых слов – "псевдонеправильные". Ну невозможно описать правилами большинство неправильных слов типа "numismatograph" и "troid".
Забегая вперёд этой части статьи, скажу, что я пришел к выводу, что из-за того, что большая часть неправильных слов — псевдонеправильные(слова, не поддающиеся отсечению по правилам), единственный вариант решения- формальными правилами уменьшить словарь настолько, насколько это возможно, скормить его блуму или аналогу(если есть), а затем перед проверкой на блуме на входе по редким комбинациям отсекать "мусор".
Это не работает. Редкие комбинации эффект дают, но не решающий.
Стемер мне тоже не помог. Сделал тупо серией sql-запросов. Сами запросы будут во второй части.
Это моей было ключевой стратегией для уменьшения размера словаря – выделить слова, включающие в себя другие слова, и закодировать, сколько букв спереди или сзади можно отбросить для получения правильных слов.
Уменьшение словаря до 390К, карта "соседских" двоек и троек, блум и ещё что-то читайте через неделю.
Проверил. Не даёт. На 1000 блоках 55.27%
Во второй части будет описание, как я уменьшил словарь до 390000 без потерь.
Напишите обязательно! Я делал почти тоже самое, и тоже дошел до уменьшения слов до около 300К+ для скармливания их блуму, но так и не успел разобраться, как сохранить результат в <64k. В лучшем случае получал 120. Напишу об этом во второй части статьи.
Я просто раньше с Azure ML не работал и не знаю что в нём есть и чего от него ожидать, поэтому пошел по более-менее понятному мне пути.
Значит Вы учли что-то, чего не учёл я. Но вроде как, кроме количества согласных подряд, я скормил тот же набор данных.
SQL база у меня была локальная. Я хотел попробовать Azure ML, но споткнулся о существенную разницу в скорости выполнения запросов между азуровским и локальным SQL-серверами. В частности, создания таблицы с несуществующими четвёрками согласных, на азуре я так и не смог дождаться. Понимаю, что можно было поработать над оптимальностью запросов, но задача была другой.
Это мало, и это те же грабли, которые я опишу во второй части. Из-за того, что в реальных тестах много повторов, 65% на уникальных словах опустятся до 50%.
На каком объеме данных? Слова были уникальными, или так, как спарсили, так и передавали, включая повторы?
Да, только она сейчас неполная. Перед тем, как скармливать данные майнингу, я убрал из неё то, что отсекается описанными в этой статье простыми фильтрами. Сейчас в ней порядка 38М слов.
Решение не отправил, но решил поделиться опытом.