Разработать проект процедуры обработки ответа студента при задании правильного ответа строкой
Issue #40
closed
Originally reported on Google Code with ID 40
Проект должен включать:
1) перечень стадий
2) для каждой стадии подробно описанные:
* выход (с описанием типов данных и т.д.)
* вход (с описанием типов данных и т.д.)
* постановку задачи (с указанием условий отбора или оптимальности если необходимо)
- что делает этап
* наименования или краткие описания алгоритмов
3) описания вводимых типов данных (например классов лексем). Если планируется наличие
множества классов-потомков, то достаточно привести описание абстрактного класса (интерфейс).
P.S. Также подумать над названием типа вопроса. Пока ставлю autofeedback, но оно слишком
общее. Надо что-то связанное с обучением синтаксису придумать...
Reported by oasychev on 2011-10-26 21:14:01
Comments (35)
-
Account Deleted
-
reporter
``` Описание стадии 3 демонстрирует вам одну вещь, которую лучше усвоить раз и навсегда: записывать что-либо по итогам нашего с вами разговора надо СРАЗУ ЖЕ, в тот же вечер. Иначе вы просто забудете важные детали. Я вам объяснял, что эти два критерия нельзя суммировать: критерий по количеству покрытых лексем имеет явный приоритет, второй - сумма расстояний Левенштейна - рассматривается только при равном первом.
Насчет классов лексем надо думать серьезнее, т.к. они должны обрабатывать типовые ошибки для данного вида лексем.
Стадия 4 Построение LCS
Стадия 5 Выбор наиболее подходящего ответа в случае, если присутствуют несколько (по максимальному проценту покрытия LCS лексем ответов приблизительно, разберите на примерах и уточните)
Стадия 6 Генерация ошибок на основе LCS (есть в правильном и проверяемом ответах, но нет в LCS - значит лексема перемещена и т.д.)
P.S. Если есть желание аутсорсить этапы 2-3, необходимо срочно проработать точные форматы входных и выходных данных (вход этапа 2 и выход этапа 3) на языке PHP чтобы человек мог работать. В этом случае принесите формат + пример в среду.
Вообще к среде обязательно сделайте 1-2 примера (правильный + проверяемый ответ), расписанные по всем этапам (хотя бы не на языке программирования, а просто), чтобы я видел насколько вы поняли задачу.
P.P.S. uerreport мне нравится еще меньше чем autofeedback. Во-первых, feedback лучше error report, во-вторых мы говорили о том, чтобы подчеркнуть в названии синтаксическую ориентированность определяемых ошибок, а этого по прежнему нет. ```
Reported by `oasychev` on 2011-11-06 17:56:42
-
Account Deleted
``` Я не совсем понял, что конкретно происходит на стадии 5 и чем это принципиально отлично от стадии 3. Кроме того, в процессе составления я понял почему так проблемно представить что происходит на стадии 2: мне банально неизвестны типичные ошибки. Вы не могли бы предоставить мне штук 5 примеров различного рода ошибок, которые может отловить этап 2?
Попробовал сделать пару примеров.
Пример 1.
Пусть на входе есть ответ вида QData a=QData::fromString(12.1.1999,"dd.M.yy"); Ответ, который должен был быть получен: QDate a=QDate::fromString("12.1.1999","dd.M.yy"); c порогом ошибок 10.
Стадия 1:
Вход: строка " QData a=QData::fromString(12.1.1999,"dd.M.yy") " Выход: лексемы Идентификатор( QData ), Идентификатор ( a ) , Присваивание, Идентификатор( QData ), Доступ к статическому методу (далее ДКСМ) ( :: ), Идентификатор( fromString ), открывающая скобка (далее ОС), число ( 12 ), точка, число(1), точка, число(1999), запятая, строка "dd.M.yy", закрывающая скобка (далее ЗС)
Стадия 2:
Вход: массив лексем полученный на предыдущем этапе, массив массивов лексем ответа, пороги Производимое преобразование: Лексемы Идентификатор ( QDate ), Идентификатор ( QDate ) исправляют опечатки в лексемах Идентификатор( QData ), Идентификатор( QData ) , лексема первой строки ответа разбирает строку внутри себя на лексемы и находит похожую последовательность внутри полученной исходной строки (похожую по лингвистическому расстоянию между ними) Выход: массив массивов исправленных лексем, при этом Идентификатор ( QDate ), Идентификатор ( QDate ) хранят ошибки вида "Опечатка в букве", а строковый литерал, совпадающий с ответом хранит ошибку "Пропущены кавычки в строке".
Стадия 3: первый ответ покрывает наибольшее количество лексем (ВСЕ), поэтому выбирается введенная исправленный согласно первому случаю
Стадия 4:
Вход: массив лексем, исправленных на стадиях 2-3, массив массивов лексем ответов Выход: построенные LCS,(в данном случае состоящая из всех лексем полученных на стадиях 2-3)
Стадия 5:
Вход: массив лексем, полученный на стадиях 2-4, массив массивов ответов. Выход: подходящим является первый и единственный ответ, соответсвенно он является выходом, массив лексем, полученный на стадиях 2-4, LCS
Стадия 6:
Вход: массив лексем первого ответа, массив лексем, полученный на стадиях 2-4, LCS Выход: в LCS входят все лексемы, значит на выходе просто массив строк с ошибками, созданный из внутренней информации лексем в ответе.
Пример 2:
Пускай ответом является следующая строка: int * a=new int[10]; for (int i=0;i<10;i++) a[i]=i; delete a; , порог ошибок - 5 А входной строкой: int a=new int[10]; for (int i=0;i<10;i++) delete a; a[i]=i;
Стадия 1:
Вход: Строка " int a=new int[10]; for (int i=0;i<10;i++) delete a; a[i]=i; " Выход: Набор лексем: Идентификатор ( int ), Идентификатор ( a ), Присваивание, Ключевое слово new, Открывающая кв. скобка , Число (10), Закрывающая кв. скобка и.т.д.
Стадия 2:
Вход: массив лексем, полученных на предыдущем этапе, массив массивов лексем ответов Выход: массив массивов исправленных лексем для каждого ответа. В данном случае никаких исправлений не происходит.
Стадия 3:
Вход: массив массивов исправленных лексем для каждого ответа. В данном случае ответ 1 покрывает лексемы максимально и поэтому Выход: массив лексем полученный на этапе 2
Стадия 4:
Вход: массив лексем полученный на этапе 2 Выход: массив лексем полученный на этапе 2, массив массивов лексем LCS соответствующий каждому ответу (в данном случае, - лексемы строки a=new int[10]; for (int i=0;i<10;i++) )
Стадия 5:
Вход: массив лексем полученный на этапе 2, массив массивов лексем LCS соответствующий каждому ответу, массив лексем ответов Выход: массив лексем полученный на этапе 2, массив лексем LCS, соответствующий выбранному ответу - 1
Стадия 6:
Вход: массив лексем полученный на этапе 2, массив лексем LCS, соответствующий выбранному ответу, массив лексем ответа Преобразование: Исходя из разницы между LCS можно массив лексем ответа и входной строки разбить на две части. Исходя из разниц, можно определить что была удалена лексема указателя (*), а заполнение и удаление массива перепутаны местами, на основе чего генерируются ошибки. Выход: полученные ошибки - "Некорректное объявление массива", "Неправильно сформирован алгоритм", с более подробно формулировкой "Перепутано удаление и заполнение масива"
P.S. Подумал об имени ещё раз. Пока пришел к названию Syntax Error Explanation, которое в результате преобразований сократил до sanexplanation.
```
Reported by `mamontov.dp` on 2011-11-08 15:46:01
-
Account Deleted
``` P.P.S Также непонятен алгоритм стадии 6. С одной стороны это простое определение типа редакционной правки (что даже описано в Вики), но с другой стороны нужно знать контекст этого перемещения, т.е. куда перемещается и откуда. ```
Reported by `mamontov.dp` on 2011-11-08 15:50:40
-
reporter
``` Стадии 3 и 5 очень разные. На стадии 2 составляются все соответствия, которые потенциально могут быть опечатками. При этом вполне может быть несколько возможных соответствий с одной лексемой, проходящих порог. На стадии 3 выбирается такой набор соответствий, который лучше подходит. И стадия 2 и стадия 3 выполняются для каждого варианта правильного ответа отдельно.
На стадии 5 выбирается наиболее подходящий правильный ответ, если их было несколько. Это можно сделать только анализируя LCS.
Пример лучше имейте на бумаге при встрече... ```
Reported by `oasychev` on 2011-11-08 19:58:58
-
Account Deleted
``` Попытался составить список и описание структур для стадий 1-3 на языке PHP. DFD для всех стадий, скорее всего, приложу завтра. ```
Reported by `mamontov.dp` on 2011-11-18 18:29:48
<hr>
- *Attachment: [datastructures.zip](https://storage.googleapis.com/google-code-attachments/oasychev-moodle-plugins/issue-40/comment-6/datastructures.zip)*
-
Account Deleted
``` Прикладываю DFD-диаграмму. ```
Reported by `mamontov.dp` on 2011-11-19 18:13:46
<hr>
- *Attachment: dfd.png<br>*
-
reporter
``` 1. Я бы советовал вам внимательно прочитать http://docs.moodle.org/dev/Coding с описанием требований к оформлению кода Moodle и следовать им с самого начала. Настроить редактор на замену табуляций на пробелы, соблюдать стили наименования и т.д. Я пока ожидал текстового документа, но раз уж вы взялись писать код - следуйте ему.
2.DFD немного неполна. Тут упущены мелкие, но необходимые данные, появляющиеся на разных этапах. Например порог отбора пар по расстоянию Левенйштейна, передаваемый из БД на этап построения пар.
3. Не забывайте про принцип YAGNI. Я пока не вижу методов/других форм обоснования для выделения правильного и неправильного ответа в отдельные классы. Чем эти классы будут принципиально отличаться от массива лексем? Вам стоило бы приучить себя к бритве Оккама.
4. Поскольку проект потенциально может быть международным, мы обычно делаем комментарии в коде по английски (это не относится к описаниям в документах). ```
Reported by `oasychev` on 2011-11-20 11:03:19
-
Account Deleted
``` 1. Будет сделано
2. Не могли бы вы описать, что именно мелкое упущено (помимо этого факта, который я исправлю?)
3. Не знаю насчёт ответа ученика, но для правильного ответа это удобно хотя бы тем, что помимо массива, туда можно внести заодно и порог для лексем. Во вторых, если нам потребуется проатрибутировать в будущем каким-то способом ответ ученика и правильный ответ тем или иным образом, будет удобнее манипулировать классом, чем отдельно массивами лексем, какими-то ещё данными. Меньше вероятности просто запутаться в данных.
4. Я в принципе-то не против, но просто этот код, как я понимаю потом придётся смотреть другому человеку, при этом русскому. У неё всё хорошо с английским? Просто не хотелось бы в последний момент тратить время на документацию ещё и к классам. Даже если так, то в можно будет просто перевести все комментарии в будущем. ```
Reported by `mamontov.dp` on 2011-11-20 12:36:54
-
reporter
``` 2. Сначала попробуйте сами подумать, каких данных не хватает тому или иному методу для работы...
3. Порог для лексем не является свойством конкретного ответа - это свойство всего вопроса, которое от ответа к ответу не меняется... Пока я не вижу таких свойств, которые бы нуждались в добавлении именно к массиву лексем - при наличии юнит-тестов рефакторинг не такая уж проблема. Работу по созданию нового класса нужно обосновать конкретными преимуществами.
В любом случае, если вы реализуете класс, в основе которого лежит массив + доп. данные - значит необходимо обеспечить возможность работы с ним как с массивом (а не через длинные названия функций) - квадратные скобки, итерирование и т.д. По PHP читаем на этот счет http://www.php.net/~helly/php/ext/spl/interfaceArrayAccess.html , http://ru.php.net/arrayobject
Или сделать массив доступным внешне...
4. Я уточню насчет того, есть ли проблемы с английским (вряд ли вы напишите очень сложные фразы). Опыт показывает, что переводить комментарии в будущем обычно ни времени, ни желания не находится... Если используются русские буквы - следите за кодировкой - UTF-8 (без BOM).
P.S. Если несложно, захватите завтра на бумаге - попробуем кое-что поправить если останется время... ```
Reported by `oasychev` on 2011-11-20 18:50:32
-
Account Deleted
``` Попробовал переделать прототипы. Заливаю исправленную версию. ```
Reported by `mamontov.dp` on 2011-11-22 14:38:14
<hr>
-
Account Deleted
``` Также поправил DFD. ```
Reported by `mamontov.dp` on 2011-11-22 15:03:34
<hr>
- *Attachment: dfd.png<br>*
-
reporter
``` Как вам writingcompetently в качестве названия вопроса? ```
Reported by `oasychev` on 2011-11-26 23:13:25
-
Account Deleted
``` Длинновато, но пойдёт. Думаю, в принципе, на нём можно остановиться. ```
Reported by `mamontov.dp` on 2011-11-28 02:35:26
-
reporter
``` Для общей координации это issue беру на себя. В ближайшее время будет выложена информация по основным типам данных.
Также здесь будем обсуждать общие вопросы, касающиеся стыковки различных модулей, если они возникнут. ```
Reported by `oasychev` on 2011-11-28 21:09:42
-
reporter
Reported by `oasychev` on 2011-11-28 21:11:25 - Labels added: Component-WritingCompetently - Labels removed: Component-Autofeedback
-
reporter
``` Наименование типа вопроса лучше утвердить сразу, т.к. его придется ставить префиксом перед всеми классами, использовать в некоторых наименованиях файлов и т.д. Пользовательское название Writing Competently (если никто не предложит лучшего). Для применения в тексте программы его лучше бы сократить. Какие будут предложения? competentwr ? ```
Reported by `oasychev` on 2011-11-30 19:23:06
-
reporter
``` Выкладываю для всеобщего ознакомления проект базового класса лексемы и пары (для лексических ошибок). Если есть вопросы - пишите... Если согласны - тоже (классы касаются главным образом Сергея и Маши).
В коде пока не используйте, т.к. нужно сделать префикс из сокращенного имени типа вопроса, о котором я просил вас высказаться (compwriting? competentwe?) и т.д. ```
Reported by `oasychev` on 2011-11-30 21:45:33
<hr>
- *Attachment: [autofeedback_tokens.php](https://storage.googleapis.com/google-code-attachments/oasychev-moodle-plugins/issue-40/comment-18/autofeedback_tokens.php)*
-
reporter
``` Выкладываю вторую часть проекта - эскизы классов, осуществляющих анализ ответов.
Прошу всех изучить и собраться опять в среду для обсуждения.
Пашаеву приготовить проект класса языка.
```
Reported by `oasychev` on 2011-12-04 22:40:51
<hr>
- *Attachment: [autofeedback_analyzers.php](https://storage.googleapis.com/google-code-attachments/oasychev-moodle-plugins/issue-40/comment-19/autofeedback_analyzers.php)*
-
reporter
``` После дополнительных размышлений (например как это будет звучать в приложении в виде существительного) было принято имя вопроса Correct Writing.
Усовершенствованные классы (и эскизы некоторых дополнительных классов) выложены в клоне http://code.google.com/r/oasychev-correctwriting/source/checkout, прошу свои клоны синхронизировать с ним. Многие внутренние функции анализаторов сделаны public дабы обеспечить возможность их раздельного юнит-тестирования. Выправлена терминология. Классы ошибок еще будут уточняться, когда подготовите примеры разных видов ошибок.
В течении двух недель (до след. встречи) необходимо приготовить минимум по 1-2 примерам юнит-тестов на каждую свою функцию и согласовать их со мной. ```
Reported by `oasychev` on 2011-12-07 23:11:22
-
reporter
``` Основной проект создан и вытолкнут. Дело за вами....
Когда следует ждать юнит-тестов? ```
Reported by `oasychev` on 2012-01-06 12:37:42 - Status changed: `Fixed`
-
reporter
``` Обращаю внимание всех, что модуль поддержки языков вынесен в отдельный блок от вопроса. Он может использоваться не только этим вопросом и должен существовать отдельно.
Модуль поддержки языков развивается в отдельном клоне oasychev-formallangs-block - Пашаеву и Бирюковой, чья работа связана с этим блоком, необходимо создать свои дополнительные клоны. В Moodle - который лучше всем иметь 2.2 - следует поставить и блок и вопрос, вопрос без блока работать не будет. Но развиваться они должны в отдельных клонах, чтобы можно было использовать отдельно... ```
Reported by `oasychev` on 2012-02-15 11:44:42
-
Account Deleted
``` Олег Александрович, позвольте небольшую просьбу: скопируйте реализацию функции is_same базового класса лексемы (...token_base) в центральный репозиторий формальных языков. Я поправил там стиль, и теперь он должен соответствовать стилю Moodle, а копирование её позволит мне избавится от проблем, связанных с нестыковками версий при слияниях и ускорить разработку, да и её можно считать завершенной. Также в моем клоне есть небольшой файл-заглушка, который позволяет худо-бедно установить новый блок (текущий блок встать не пожелал почему-то). Также, в моем клоне есть исправление опечатки в version.php самого типа вопроса, из-за чего также возникли проблемы при обновлении вопроса. ```
Reported by `mamontov.dp` on 2012-02-15 15:03:12
-
reporter
``` А что мешает вам самому сделать клон и добавить реализацию этой функции? Разницы никакой нет.
Если у вас при слиянии файлы назад создадутся - удалите их снова (при слиянии или отдельным коммитом), вот и все... ```
Reported by `oasychev` on 2012-02-16 11:28:17
-
reporter
``` Вытягивать код блока в репозиторий вопроса - не нужно и недопустимо! Эти коммиты надо удалить. Для работы с репозиторием блока необходимо создать отдельный клон от моего клона с блоком и коммитить изменения блока туда.
Наборы изменений с кодом блока внутри клона для вопроса вытягивать не буду. Они должны быть независимы и мержиться только в центральном репозитории при релизе. ```
Reported by `oasychev` on 2012-02-16 11:33:09
-
Account Deleted
``` Зачем мне плодить клон для того, чтобы добавить одну готовую маленькую реализованную функцию? Почему бы просто её не скопировать в центральный репозиторий? Судя по всему больше у меня изменений в этой части не будет, соответственно, по-моему нет адекватной причины, чтобы заводить клон. Для второго случая - тем более, там появился только один файл, который по непонятным причинам у вас отсутствовал. ```
Reported by `mamontov.dp` on 2012-02-16 14:42:08
-
Account Deleted
``` И да, заметьте, в комментарии 23 я просил именно скопировать. Мой текущий клон, не пойдет в релиз ни при каких условиях. Сейчас он используется для того, чтобы фиксировать исправления. ```
Reported by `mamontov.dp` on 2012-02-16 14:48:56
-
reporter
``` Значит вы плохо понимаете workflow при распределенном контроле версий.
Во-первых клон - операция дешевая, и не проблема завести его для пары изменений. Потом удалить можно без проблем. А может и еще что-нибудь полезное припишите.
Во-вторых в норме когда ваша работа готова, она вытягивается из вашего клона в основной (релизный). Вместе со всей историей кода. Поэтому фразу "мой текущий клон не пойдет в релиз ни при каких условиях" можно понимать только как "я все равно не сделаю ничего достойного релиза" - что врядли. Поэтому история должна быть правильной и чистой с самого начала. В процессе работы над вопросов я буду вытягивать ваши изменения в центральный клон (свой), а к релизу - из него в основной репозиторий.
А если уж просто речь идет о том, чтобы добавить файл к проекту - пришлите его аттачем к issue. А из клона удалите... Класс блока должен был дорисовать другой человек, моя задача была структурно распределить чтобы было ясно что где. И времени у меня сейчас ОЧЕНЬ мало. ```
Reported by `oasychev` on 2012-02-17 11:38:38
-
reporter
``` Файл добавил, поправив очевидные ошибки (кавычки, строка выводимая пользователю должна браться через get_string). Тестировать здесь не на чем, проверьте вы.
Удалите все что касается блока из вашего клона по вопросу. ```
Reported by `oasychev` on 2012-02-17 13:18:26
-
Account Deleted
``` Проверил - всё работает. Репозиторий формальных языков склонировал, внёс туда is_same и тест этой функции, прошу проверить стиль, вроде должен соответствовать. ```
Reported by `mamontov.dp` on 2012-02-17 16:54:07
-
reporter
``` Недостаток тестов - неинформативность сообщений, в таком виде можно их вообще не писать (ассерт все равно выдаст строку и функцию при провале). К последнему тесту вы перестали ставить пробелы вокруг присваивания, в остальном стиль вроде в порядке.
А вот в анализаторе, похоже, часть кавычек все еще двойная... ```
Reported by `oasychev` on 2012-02-18 22:25:13
-
Account Deleted
``` Исправил все указанные ошибки. Однако насчет неинформативности возникла проблема - каково рода сообщения я должен выдать при провале? В принципе, там можно просто сказать , что функция рассчитывается неверно, но это не менее неинформативно. ```
Reported by `mamontov.dp` on 2012-02-19 06:28:15
-
reporter
``` В принципе, как я сказал, в случае если в функции один ассерт и название самой функции информативно, сообщения можно и не писать. Я не зря назвал это только недостатком. Но например в функциях на несовпадение можно было бы вписать сообщение что функция посчитала лексемы равными хотя тип различен - тут указывается конкретно какая ситуация не сработала. ```
Reported by `oasychev` on 2012-02-19 18:12:18
-
reporter
``` Общие собрания-консультации по типу вопроса correctwriting будут проходить по субботам второй недели, с 14 часов на кафедре. Быть в полном составе.
Дополнительные индивидуальные консультации по выпускным работам: Пашаев - вторник второй недели, 13-30 Мамонтов - пятница первой недели, 16-00 ```
Reported by `oasychev` on 2012-03-20 11:39:07
-
reporter
Reported by
oasychevon 2013-01-27 15:50:47 - Status changed:Done - Log in to comment
*){kind=link}
*){kind=link}
``` Обдумал название. Пока пусть будет uerreport (cокращение от Understandable Error Report, т.е. понимаемое сообщение об ошибке). Все стадии продумать не удалось пока приведу те, которые более менее понял: 1) Модифицированный лексический разбор строки 2) Поиск и выявление опечаток и их типа 3) Выбор наилучшего совпадения из прошедших порог
Стадия 1. Вход: строка, массив описаний лексем, на которые может строка разбиваться (набор из регулярных выражений и действий, связанных с ними) Выход: массив лексем, на которые разбита строка, в котором для каждого нового неопознанного символа заводится отдельная новая лексема на символ, и массив их положений Алгоритм: классический разбор на лексемы с модификацией для удовлетворения условий выхода
Стадия 2
Вход: массив лексем, которые были получены на предыдущем этапе, массив лексем строк ответов (возможно с внутренней оценкой корректности ответа), массив порогов соответствия для каждой строки ответа. Выход: массив массивов исправленных лексем, при этом каждая лексема хранит исправления которые были сделаны в тексте, чтобы получить её точной. Каждый массив соответствует определённому ответу, при этом из общего списка отбираются только те массивы, которые удовлетворяют порогу. Скорее всего, лексемы строки ответов, должны быть абстрактными классами, у которых есть один метод, принимающий на входе текущую позицию в наборе лексем и просматривающую её с этой позиции вперёд.
Стадия 3 Выбор наилучшего совпадения
Вход: выход предыдущего этапа
Выход: массив лексем, с наилучшим совпадением Критерий оптимальности: наименьшее число опечаток при наибольшем индексе корректности ответа. Общий критерий определяется через сумму перемножений оценки числа опечаток на вес данного критерия и критерия корректности ответа на вес данного критерия ```
Reported by `mamontov.dp` on 2011-11-06 17:35:37