1. Ок. Имеем Primary Key + BLOB. BLOB — может быть каком угодно формате. Скажем, JSON. В чем сложность? Если запросы не по индексу, все равно нужно просматривать все записи.
2. Суть в том, что просто SQL не бывает. Так же как NoSQL
3. А что? в sql глазами данные посмотреть сильно проще.
Имхо:
1. Чем принципиально NoSQL отличается от простых запросов по primary key?
2. SQL плох тем, что у каждого производителя СУБД свой диалект.
3. Делать аналитику на SQL сильно проще.
4. Интересным подходом кажется HandlerSocket + MySQL — обход SQL уровня и прямой доступ к таблицам по ключам.
Да-да. По коду видно, что это какие-то вычисления. Автору было бы неплохо написать, что этот код решает такую-то задачу. Конечно можно по функциям сидеть и разбирать и найти известные алгоритмы, но у меня не возникает желания напрягать мозг для этого.
Смотреть не только на отдельные словоформы, но и на контекст, кажем ± 2 слова.
Насколько я понимаю, примерно так работает hmm-подход(конечно, в этом случае есть только левый контекст).
Кроме того, скорее всего это очень сильно зависит от количества тегов — есть же деление на fine-grained POS, и coarse-grained POS.
Насколько я понимаю, еще один вариант POS Tagging — это обучение без учителя. Т.е. скорее всего можно взять много текстов, поделить их по словоформам и выделить классы. Вероятно, что эти классы будут более-менее соответствовать частям речи.
Ну и возможны смешанные варианты, конечно(semisupervised learning).
Не отменяет :) но облегчает жизнь. В частности для вышеприведенной задачки.
Я не вижу особого смысла в задачках на лексический анализ(читай буквоедство), когда соль задачки в том, что «не скомпилируется, потому что вот тут забыли ';' поставить».
Классический i+++++i тоже не всегда полезен, потому как такого кода не должно быть, независимо от того понимает написавший тонкости работы или нет — читать это очень сложно.
Это примерно как проверка орфографии сложных слов. Оно конечно коррелирует с кругозором и умением излагать свои мысли, но это не строгая зависимость.
Имхо, недостаток таких задач в том, что если знать о существовании такой задачи, то все тривиально.
Ну и я не очень понимаю их смысла, IDE для того и нужен, чтобы все красиво и понятно раскрасить, а не заставлять
программиста делать лексический анализ в голове.
Да и не во всех NoSQL есть сортировка.
2. Суть в том, что просто SQL не бывает. Так же как NoSQL
3. А что? в sql глазами данные посмотреть сильно проще.
1. Чем принципиально NoSQL отличается от простых запросов по primary key?
2. SQL плох тем, что у каждого производителя СУБД свой диалект.
3. Делать аналитику на SQL сильно проще.
4. Интересным подходом кажется HandlerSocket + MySQL — обход SQL уровня и прямой доступ к таблицам по ключам.
Вспоминается анекдот: «А потом пришел лесник и всех разогнал».
А какой у вас объем обучающей/проверочной выборки? И, собственно, откуда набор данных? Сами размечали?
А какие признаки из html вы используете? Вряд ли система предназначена для работы на plain-text.
В этом смысле Портер лучше :)
В нормальных редакторах он есть.
Насколько я понимаю, примерно так работает hmm-подход(конечно, в этом случае есть только левый контекст).
Кроме того, скорее всего это очень сильно зависит от количества тегов — есть же деление на fine-grained POS, и coarse-grained POS.
Ну и возможны смешанные варианты, конечно(semisupervised learning).
Не скомпилируется, если java < 1.5 из-за vararg
Я не вижу особого смысла в задачках на лексический анализ(читай буквоедство), когда соль задачки в том, что «не скомпилируется, потому что вот тут забыли ';' поставить».
Классический i+++++i тоже не всегда полезен, потому как такого кода не должно быть, независимо от того понимает написавший тонкости работы или нет — читать это очень сложно.
Это примерно как проверка орфографии сложных слов. Оно конечно коррелирует с кругозором и умением излагать свои мысли, но это не строгая зависимость.
Ну и я не очень понимаю их смысла, IDE для того и нужен, чтобы все красиво и понятно раскрасить, а не заставлять
программиста делать лексический анализ в голове.