LisaST, во-первых, у меня была дурацкая ошибка в скрипте tag-uni. Исправил (см. соответствующий пост); во-вторых, была небольшая ошибка в tag-norm (исправил, см. там же). И наконец, скрипт, подсчитывающий в нормализованных файлах Recall & Precision. Его нужно проверять, не напутал ли я чего. Успехов!

amg, пара замечанияй по последнему фрагменту. Так мелкие придирки...



Понятие "релевантность" - самое сильное из числа "найдено тэггером", "найдено goldStandart" и "найдено тэггером релевантных". Т.е. потенциально существует вероятность, что релевантных слов просто не будет для определенного типа. Вероятность небольшая (на большом тексте), но она есть. Проблема решается путем создания "множества типов слова" или T.  



И еще. Ты не проверяешь равенство слов (только их количество). В принципе, если исходные тексты были проверены "на пословное равенство",  это не критично. 

...

Да, это разумно. Добавлю только, что тогда придется вводить проверки на существование тэгов в %N, %NT, %NG, а то получим предупреждения и ошибки при действиях с неопределенными величинами.

Тоже верно. По хорошему, надо бы проверять на равенство слов, но лень было.

Можно и так. На всякий случай я добавил в нормализующий скрипт (tag-norm) вывод на stdout удаляемых слов. Это желательно еще и потому, что нормализация - очевидно, самая медленная операция, и будет лучше если программа будет подавать признаки жизнедеятельности. Также в этом скрипте исправил ошибки.

И, наконец, некоторые соображения философского плана.
Zuzu отлично показал, как данный проект можно оформить с помощью ООП и модулей. Я использовал несколько иной подход, применимый для консольных приложений: каждую операцию делает отдельный независимый маленький скрипт, причем эти скрипты способны взаимодействовать друг с другом (через файлы, а лучше, где это возможно, и через pipe). В любом случае главное - не пихать все в одну программу. Такие скрипты легко скомбинировать в shell-сценарии, например, для GoldStandard и CRFTagger (почему то у меня создалось впечатление, что у LisaST *nix, поэтому bash-сценарий)

только наоборот: Recall(t) = (N(t) / NG(t)) * 100%
                              Precision(t) = (N(t) / NT(t)) * 100%
  


вау, я даже не знала, что в перле есть такая конструкция- очень практично



у меня в университете Linux, на работе windows, то есть, если что-то простое для обработки текста требуется- то стараюсь сделать в shell, но иногда приходится использовать уже готовые perl программы, поэтому пришлось в нем немного разобраться

а что здесь имелось ввиду, какой-то формат вывода данных?


 

вам обоим огромное спасибо, особенно амг за код, мне кажется, что даже можно статью из этого thread напечатать, т.к. в России очень мало работ на эту тему на русском языке



я так поняла,что zuzu мог бы этим заинтересоваться

Именно. Печать по формату, (почти) так же, как в С. Означает печатать 1-ю переменную в виде строки, затем знак "=", 2-ю переменную как целое число, 3-ю как десятичное число с 2-мя знаками после запятой, 4-ю так же и, наконец, 2 пробела. Переменные перечисляются следом через запятую. См. perldoc -f sprintf (и man 3 printf для дополнительных подробностей). (sprintf отличается о printf только тем, что не выводит результат на печать, а возвращает его).

Кстати, при работе в windows можно использовать perl как замену grep/sed/awk/... Есть даже коллекциии консольных команд, так называемые однострочники (one-liners). (Только при использовании таких команд в windows нужно разобраться с кавычками.

Исправил. Прошу прощения за ошибку.

LisaST, у тебя получился то результат, который ты ожидала при обработке текста? Вопрос интересует, скорее из соображения, можно ли считать задачу решенной (по крайней мере на каком-то этапе). 

Если так, мои поздравления участникам! (занавес, аплодисменты, шампанское!). Благодарю amg за очень компактное решение задачи - мне бы так коротко не написать. А LisaST хочется поблагодарить за терпеливое отношение к моим, порой глупым и невмеру ехидным вопросам. Еще раз, всем спасибо.

А про статью - подумаю. 

С удовольствием присоединяюсь!

Добавлено

Сроднился я уже с этим проектом, никак не отпускает   
Вот проверил производительность скриптов на файлах, состоящих из 40 тыс.предложений (по ~1.2 млн. слов).

Unification of tags - по 3-4 s
Normalization - 38 s
Test of normalized files  - 3 s
Count Recall & Precision - 6 s

Как и следовало ожидать, самая времязатратная операция - нормализация. В принципе, если запускать все это с консоли, то, IMHO, вполне нормально. Хотя можно и ускорить (кое-что в скриптах сделано не оптимально). LisaST, надо ли?

Это сообщение отредактировал(а) amg - 1.2.2007, 15:08

шампанское скорей от меня 

я буду в командировке до 15.02, поэтому, к сожалению, не разобралась с тегами для нормализации...но feedback обязательно будет



я думаю, ускорять не надо...второй memm теггер вообще около часа теги присваивает, поэтому такая скорость очень хороша 

to amg: 

попробовала сегодня протестировать скрипт, если копирую то, что вы мне написали для shell, то окно просто закрывается, видимо выполняется exit


просто для тестирования попробовала таким способом (тестирую пока только сущ)

LisaN@Lisa /home/CRFTagger/evaluierung
$ cat gold.pos.txt | perl tag_good.pl | perl tag_uni.pl -G > goldstandard.pos.u
ni

LisaST, рад приветствовать Вас !
 С этим надо разобраться. Гораздо удобнее будет.
1. Убедитесь, что у Вас последние версии всех скриптов (я их неоднократно правил, сообщая об этом и внося изменения в тех постах, где они были приведены)
2. Какой у Вас shell? ls -l /bin/sh что говорит? У меня /bin/sh - это симлинк на bash.
3. Если bash, то добавьте 2-й строчкой set -x, чтобы посмотреть, где скрипт вылетает.

И еще. Думаю, что не стоит выбрасывать из текста какие-либо слова/теги (tag_good.pl), даже знаки препинания. Ведь существует же отличная от 0 вероятность, что какой-нибудь совсем дурной тэггер пометит, скажем, точку как существительное. И если это произойдет, то статистика после удаления точек будет неправильной.

добрый вечер,

я тестировала в cygwin bash shell, добавила set x,опять просто закрывается окно.
tag_good попробовала пока просто как тест...

Уж не знаю, что и думать. 
Может такое быть: если файл был сохранен в win(dos)-формате, а cygwin думает, что файл в unix-формате, и если 1-й строкой идет #!/bin/sh, то cygwin будет искать в качестве запускалки скрипта не "/bin/sh", "/bin/sh\n....", и естественно, не найдет и скрипт исполнять не будет. И наоборот, cygwin может ожидать, что файлы в win(dos)-формате, а они не такие. Выход - перевести файл в нужный формат (любой програмистский редактор это умеет). Скорее всего, в unix-формат (default для cygwin'а).

А если создать скрипт с единственной командой, например, date, он будет исполняться?

вроде как теперь запускается, но пишет, что в строке 33 (строка , следующая за последней )ошибка, только я не знаю какая