Нет ли способа выбора "рандомного" вопроса из категории при котором один и тот же вопрос не может быть выдан более 1 раза (при условии, что число вопросов больше, чем число сдающих) ? У сдающих одна попытка.
Существует два вида рандомности:
1) если вы случайным образом вынули карту из колоды, то следующим участникам достанутся только оставшиеся в колоде карты;
2) после вытягивания карты, ее возвращают обратно в колоду и следующий участник, как и вы, может вытащить любую карту из полной колоды.
Увы, в Moodle всюду реализуется только вариант 2. А мне бы хотелось, чтобы в параметрах каждой рандомной деятельности можно было выбирать вариант, который мы хотим использовать в каждом конкретном случае. И это, на самом деле, не так уж трудно запрограммировать. Но почему это до сих пор никто не сделал, для меня остается загадкой.
Вариант 1 мне приходилось видеть только в плагине случайное задание. Там первую колоду раздают по методу 1, а потом переключаются на метод 2. А мне бы хотелось, чтобы метод 1 оставался, и после раздачи первой колоды раздавали бы вторую, третью и т.д. Чтобы количество одинаковых карт на руках всегда было минимальным.
Если бы была таблица со счетчиком использования каждого вопроса, то проблема решаласть бы легко.
Жаль, что сейчас на это времени нет.
А за плагин - спасибо.
Жаль, что сейчас на это времени нет.
А за плагин - спасибо.
Вопрос возникает регулярно в разных ветках, поэтому внимательно посмотрел код и комментарии к нему.
Вот мой прошлый пост на эту тему https://moodle.org/mod/forum/discuss.php?d=371757#p1499223
Начиная с версии 2.9, благодаря задаче MDL-6340 в moodle используется следующий алгоритм выбора вопросов.
Для каждого из студентов выбираются (при возможности), вопросы, которые он ещё не использовал. При этом просмотр этих вопросов другими студентами не учитывается. То же самое относится к наборам данных, которые есть в вычисляемых вопросах - берется, по возможности, новый набор данных. Вопросы должны начать повторяться только после того, как все по одному разу будут отображены. После того, как начнут повторяться, опять будут выбираться более редкие варианты, пока не возникнет ситуация, что все вопросы отображены по 2 раза, и так далее. Предпросмотры и незаконченные попытки тестирования не учитываются.
Смотрю по коду, поэтому просьба это окончательно подтвердить опытным путём.
Теперь о том, как это исправить.
Выбор осуществляется в mod/quiz/locallib.php -> \quiz_start_new_attempt.
Используется стратегия выбора вопросов с наименьшим числом использования, см.
$variantstrategy = new core_question\engine\variants\least_used_strategy($quba, $qubaids)
Сюда передается условие на поиск использованных вопросов $qubaids.
Сама $qubaids определена в начале процедуры.
$qubaids = new \mod_quiz\question\qubaids_for_users_attempts($quizobj->get_quizid(), $attempt->userid);
копируем mod/quiz/classes/question/qubaids_for_users_attempts.php в mod/quiz/classes/question/qubaids_for_all_attempts.php, внутри переименовываем таким же образом название класса. Меняем в конструкторе
$where = 'quiza.quiz = :quizaquiz AND quiza.userid = :userid';
$params = array('quizaquiz' => $quizid, 'userid' => $userid);
на
$where = 'quiza.quiz = :quizaquiz';
$params = array('quizaquiz' => $quizid);
в mod/quiz/locallib.php -> \quiz_start_new_attempt меняем
$qubaids = new \mod_quiz\question\qubaids_for_users_attempts($quizobj->get_quizid(), $attempt->userid);
на
$qubaids = new \mod_quiz\question\qubaids_for_all_attempts($quizobj->get_quizid(), $attempt->userid);
и аналогично в mod/quiz/attemptlib.php ->\quiz_attempt::process_redo_question, не разбирался, за что именно отвечает это место, но там тоже используется.
прикидываю, что путём расширения класса \qubaid_join и всяких манипуляций с sql возможно расширить это место так, чтобы вопросы не повторялись только внутри одной группы, потока или какого-то интервала времени
Вот мой прошлый пост на эту тему https://moodle.org/mod/forum/discuss.php?d=371757#p1499223
Начиная с версии 2.9, благодаря задаче MDL-6340 в moodle используется следующий алгоритм выбора вопросов.
Для каждого из студентов выбираются (при возможности), вопросы, которые он ещё не использовал. При этом просмотр этих вопросов другими студентами не учитывается. То же самое относится к наборам данных, которые есть в вычисляемых вопросах - берется, по возможности, новый набор данных. Вопросы должны начать повторяться только после того, как все по одному разу будут отображены. После того, как начнут повторяться, опять будут выбираться более редкие варианты, пока не возникнет ситуация, что все вопросы отображены по 2 раза, и так далее. Предпросмотры и незаконченные попытки тестирования не учитываются.
Смотрю по коду, поэтому просьба это окончательно подтвердить опытным путём.
Теперь о том, как это исправить.
Выбор осуществляется в mod/quiz/locallib.php -> \quiz_start_new_attempt.
Используется стратегия выбора вопросов с наименьшим числом использования, см.
$variantstrategy = new core_question\engine\variants\least_used_strategy($quba, $qubaids)
Сюда передается условие на поиск использованных вопросов $qubaids.
Сама $qubaids определена в начале процедуры.
$qubaids = new \mod_quiz\question\qubaids_for_users_attempts($quizobj->get_quizid(), $attempt->userid);
копируем mod/quiz/classes/question/qubaids_for_users_attempts.php в mod/quiz/classes/question/qubaids_for_all_attempts.php, внутри переименовываем таким же образом название класса. Меняем в конструкторе
$where = 'quiza.quiz = :quizaquiz AND quiza.userid = :userid';
$params = array('quizaquiz' => $quizid, 'userid' => $userid);
на
$where = 'quiza.quiz = :quizaquiz';
$params = array('quizaquiz' => $quizid);
в mod/quiz/locallib.php -> \quiz_start_new_attempt меняем
$qubaids = new \mod_quiz\question\qubaids_for_users_attempts($quizobj->get_quizid(), $attempt->userid);
на
$qubaids = new \mod_quiz\question\qubaids_for_all_attempts($quizobj->get_quizid(), $attempt->userid);
и аналогично в mod/quiz/attemptlib.php ->\quiz_attempt::process_redo_question, не разбирался, за что именно отвечает это место, но там тоже используется.
прикидываю, что путём расширения класса \qubaid_join и всяких манипуляций с sql возможно расширить это место так, чтобы вопросы не повторялись только внутри одной группы, потока или какого-то интервала времени
Спасибо, Вадим!
Сейчас, к сожалению, у меня сейчас нет времени с кодом экспериментировать. А что вы скажете по поводу изложенных ниже соображений?
Мы хотим, чтобы в каждой попытке разным студентам выпадали разные вопросы, а если этого нельзя избежать, (поскольку студентов больше, чем вопросов), то чтобы вопросы повторялись минимальное число раз: раздали первую колоду, начинаем раздавать вторую, за ней третью и т.д.
Точно так же мы хотим, чтобы у каждого студента в разных попытках вопросы тоже не повторялись, а если этого нельзя избежать, (попыток больше, чем вопросов), то чтобы и здесь тоже вопросы повторялись минимальное число раз.
Разве эти два желания противоречат друг другу? Конечно же нет!
Допустим есть N вопросов. Представляю себе матрицу NхN, где строкам соответствуют студенты, а в столбцам попытки (или наоборот). Число в матрице - это выпавший номер вопроса. Разве нельзя построить матрицу без одинаковых чисел в любой строке и столбце? Конечно же можно, и не одну. Вот пример для N=4:
1234
2341
3412
4123
А если студентов или попыток больше, чем 4, то продолжаем копировать столбцы этой матрицы вправо, а строки - вниз.
Получается, что параметры рандомности можно и не указывать в настройках тестов, а вместо этого создать единый алгоритм выбора, где количество повторяющихся вопросов всегда будет если не нулевым, то минимально возможным.
Я даже алгоритм придумал. Сначала заполняем матрицу как показано выше: с помощью счетчика и циклического сдвига. Потом случайным образом переставляем (перетасовываем) в ней строки и столбцы.
moodle за один раз подбирает вопросы для попытки тестирования не всей группе, а конкретному студенту. Поэтому он может учитывать что было до этого, но не может планировать наперед. А в базе может быть что угодно, ведь вопросы могут использоваться не только в этом тесте, и могли выпадать до этого по-разному.
Алгоритм, который используется сейчас, перед выбором случайного вопроса отсекает все варианты, которые уже использовались больше минимального числа раз. То есть этот алгоритм уже есть в системе, и он используется.
Осталось только разобраться, что в него передавать как число использований вопроса.
* Если передаём число использований текущим студентом, получаем то, что имеем сейчас. Студент не будет получать вопросов, которые видел, пока это возможно. Идеально для дистанционного обучения, где студенты не общаются.
* Если передаём число использований всеми студентами, то вроде бы получается следующая ситуация. в банке 10 вопросов, 10 студентов сдали тест первый раз, каждому попался уникальный. Сдают второй раз - первому студенту с вероятностью 1/10 попадается вопрос, который у него у же был (так как все вопросы использованы по разу, для второй попытки выберется новый из всех). Что хуже, что студент на пересдаче может получить такой же вопрос, или то, что студенты за соседними компьютерами могут получить одинаковые вопросы?
Получается нужно минимизировать обе величины. Но задача о минимизации с двумя параметрами - это совсем не то, что минимизация с одним параметром - минимум для одного параметра может не быть минимумом для другого.
Как варианты - свести это в одну величину, расставив весовые коэффициенты, или всегда в первую очередь минимизировать один параметр, а уже потом минимизировать второй, из оставшихся вариантов.
Но для этого всё-равно нужно определиться, что для Вас хуже - повтор у студента, или совпадение вопроса с другим студентом.
Алгоритм, который используется сейчас, перед выбором случайного вопроса отсекает все варианты, которые уже использовались больше минимального числа раз. То есть этот алгоритм уже есть в системе, и он используется.
Осталось только разобраться, что в него передавать как число использований вопроса.
* Если передаём число использований текущим студентом, получаем то, что имеем сейчас. Студент не будет получать вопросов, которые видел, пока это возможно. Идеально для дистанционного обучения, где студенты не общаются.
* Если передаём число использований всеми студентами, то вроде бы получается следующая ситуация. в банке 10 вопросов, 10 студентов сдали тест первый раз, каждому попался уникальный. Сдают второй раз - первому студенту с вероятностью 1/10 попадается вопрос, который у него у же был (так как все вопросы использованы по разу, для второй попытки выберется новый из всех). Что хуже, что студент на пересдаче может получить такой же вопрос, или то, что студенты за соседними компьютерами могут получить одинаковые вопросы?
Получается нужно минимизировать обе величины. Но задача о минимизации с двумя параметрами - это совсем не то, что минимизация с одним параметром - минимум для одного параметра может не быть минимумом для другого.
Как варианты - свести это в одну величину, расставив весовые коэффициенты, или всегда в первую очередь минимизировать один параметр, а уже потом минимизировать второй, из оставшихся вариантов.
Но для этого всё-равно нужно определиться, что для Вас хуже - повтор у студента, или совпадение вопроса с другим студентом.