Sujets individuels uniques

[djinn]

Bonsoir à tous,

J'aimerais utiliser Pyromaths pour générer des sujets uniques et individuels.

Grossièrement, l'idée serait d'appeler pyromaths (via la ligne de commande ou directement en python) en fournissant notamment une valeur racine pour le générateur aléatoire, et en récupérant le fichier PDF correspondant (il faudrait pouvoir reproduire le même sujet ultérieurement, à partir de cette valeur racine). En gros, une simple boucle permettrait de générer le nombre de sujets nécessaire.

Idéalement, il faudrait aussi pouvoir définir les exercices concernés, s'il s'agit d'un sujet ou/et d'un corrigé, et probablement d'autres détails encore -- que j'envisagerais de coder en dur dans un premier temps.

Aussi, je me pose plusieurs questions:

• Est-ce que l'idée a déjà été évoquée? J'ai beau chercher, je ne trouve rien…
• Si non, comment vous y prendriez-vous pour aborder ce problème, en accord avec le design de pyromaths?
• Une solution consiste à utiliser des options en ligne de commande (grâce à la librairie argparse, par exemple). Serait-ce envisageble?

Merci!

[Jérôme]

il faudrait pouvoir reproduire le même sujet ultérieurement, à partir de cette valeur racine

Je n'ai pas compris cette partie.

[djinn]

Je veux dire par là que j'aimerais pouvoir générer le même sujet (ou son corrigé) ultérieurement, en fournissant à pyromaths la même valeur racine destinée à initialiser son générateur de valeurs aléatoires. En gros, j'aimerais faire un:

Code: Tout sélectionner

random.seed(cli_param)

…au démarrage de pyromaths afin de pouvoir générer 2 fois le même sujet "aléatoire".

L'idée c'est de pouvoir imprimer un sujet (sur lequel figure cette seed), et pouvoir ultérieurement générer son corrigé en fournissant la même valeur à pyromaths. Il me faut donc un système assurant la reproductibilité du processus de génération aléatoire des exercices.
Est-ce que c'est plus clair? :-/

[Jérôme]

En effet, c'est plus clair. Quel serait l'intérêt d'un tel procédé ?

[jbreizh]

hello,
je ne comprends pas plus surtout que pour refaire exactement le même pdf tout est dejà stocker dans le .tex . Si tu veux le recompiler en ligne de commande:
latex -interaction=batchmode fichier.tex
dvips -q fichier.dvi
ps2pdf -sPAPERSIZE#a4 fichier.ps fichier.pdf

D'un point vue plus "philosophique", quand on sait exactement ce que l'on veut, on ne se sert pas d'un générateur aléatoire. Pour la petite histoire, j'ai présenté mon projet (actimaths) à une collègue et je vous cite texto:
Elle: "Et si je veux 24,56 + 1,56"
Moi: "Ce n'est pas comme ça que cela fonctionne, on a des nombres entre un min et un max"
Elle: "Bah c est nul"
Moi " (fais toi tes ppts à la main)"

[djinn]

En effet, c'est plus clair. Quel serait l'intérêt d'un tel procédé ?

Pardonne-moi, je ne suis pas certain d'avoir compris de quel procédé tu parles exactement. Dans le doute:

• Sujets individuels: j'ai 150 étudiants et, malgré ma vigilance, des problèmes de triche récurrents qui biaisent l'évaluation de façon inacceptable.
• Identification des sujets individuels par un nombre (de 3 chiffres par ex): pouvoir générer la correction correspondante au sujet que je suis en train de corriger, sans avoir à stocker et organiser 150 fichiers tex d'exercices et 150 fichiers tex de correction individuelle par examen et par promo.
• Initialiser le générateur aléatoire avec ce nombre: pour pouvoir bénéficier d'une reproductibilité parfaite à un "coût" quasi-nul. La fiche d'exercice et le corrigé sont réduits à un nombre de 1 octet (compression maximale!).
• Idéalement, il y a un code-barre (type QR code) sur la fiche PDF d'exercices: en phase de correction, je scanne ce code et la correction correspondante s'imprime.

@jbreizh: j'espère avoir répondu ci-dessus à ta première question: j'aimerais éviter d'avoir à stocker tous ces fichiers (tex ou pdf) d'exercices et de corrigés, de les chercher, de les archiver, etc. Bien entendu, quand il n'y a qu'un seul sujet ce problème n'existe pas; avec un sujet par étudiant, en revanche…

D'un point vue plus "philosophique", quand on sait exactement ce que l'on veut, on ne se sert pas d'un générateur aléatoire

Lorsqu'on génère 2 fois le même exercice avec pyromaths, on n'obtient pas les mêmes valeurs car celles-ci sont (en partie) aléatoires: et c'est exactement ce que l'on veut.

[djinn]

Bon, j'ai l'impression que cette affaire de générateur aléatoire nous fait perdre de vue le sujet principal de ce fil: générer des fiches individuelles d'exercices. :-p

Comme un exemple vaut mieux qu'une longue description, voici un patch minimaliste permettant d'initialiser ce générateur aléatoire via une option en ligne de commande:

------------------------------- src/pyromaths.py -------------------------------
index 4f74ebb..028d5e8 100755
@@ -56,6 +56,20 @@ def main():
     packagesdir = join(CONFIGDIR,  "packages")
     if not isdir(packagesdir): makedirs(packagesdir)
 
+    #===========================================================================
+    # Parse les arguments et lance l'application
+    #===========================================================================
+    from argparse import ArgumentParser
+
+    parser = ArgumentParser(description=
+                            "Pyromaths generates maths problems and solutions.")
+    parser.add_argument('-s', dest='seed', action='store',
+                        help='initialize random generator with custom seed')
+    args = parser.parse_args()
+    if (args.seed):
+        import random
+        random.seed(args.seed)
+
     app = QtGui.QApplication(argv)
     pyromaths = StartQT4()

Usage:

Code: Tout sélectionner

$ ./pyromaths.py -s SEED

Si on lance deux fois pyromaths avec la même seed, on générera deux fiches d'exercices avec des valeurs identiques (à condition qu'on choisisse les mêmes exercices et dans le même ordre, bien entendu).

Accessoirement, argparse permet l'affichage d'une description, ainsi que d'une aide automatique grâce aux options -h ou --help:

Code: Tout sélectionner

$ ./pyromaths.py -h
usage: pyromaths.py [-h] [-s SEED]

Pyromaths generates maths problems and solutions.

optional arguments:
  -h, --help  show this help message and exit
  -s SEED     initialize random generator with custom seed


[djinn]

En complément: je me rends compte que tout cela ne correspond pas nécessairement aux objectifs fixés pour pyromaths et je comprendrais que les leaders du projet ne souhaitent pas ajouter des fonctionnalités inutiles à sa communauté.
Sachant que je compte développer du code dans ce sens pour mon usage personnel (au moins), j'imagine néanmoins que certaines sous-parties de mon problème peuvent s'avérer compatibles avec les objectifs de pyromaths, auquel cas leur code pourrait intégrer le tronc commun. Par exemple: supporter certaines options en ligne de commande. J'aurai besoin d'avis plus éclairés pour déterminer quelles peuvent être ces sous-parties communes.
Je suis également preneur de toute suggestion sur la meilleure manière d'arriver à mes fins, au regard de la base de code existante notamment.

[jbreizh]

hello,
je ne suis pas le plus caler pour te répondre, mais je me lance:

- Une feuille d'exercice finie est le résultat d'un ensemble de choix fait au hasard (tel nombre, telle forme)
- Tous ces choix sont faits par la commande random.randrange (enfin grosso modo) et sont donc aléatoires (très très très pseudo)

Du coup pour générer a coup sur la même page, je vois 2 options:

- stocker tout les choix qui ont été fait, pour les réinjecter dans l'exercice..... je ne vois pas l'interêt d'une telle solution vs le stockage du tex
- créer un générateur de nombre pseudo aléatoire qui recréé la même série avec le même paramètre, puis venir modifier tous les appels à random dans le code et prevoir un moyen de rentrer ta clef. Mais tous les nombres générés au hasard n'ont pas les mêmes extremums du coup ????? je sêche.

Voilà pour mes réflexions sur le sujet, mais il est clair que n'étant pas confonté à ta problématique, mon imagination n'est pas à 100%. Perso, ce que je ferais:

- modification de vignette.py (le fichier que l'on utilise pour créé les vignettes) pour qu'il me fasse mes sujets et corrigés en boucle avec un nom itératif style sujet{numero}-eleve{numero}-sujet.tex
- stockage de tous ces tex dans un dossier au nom du sujet
- un petit script bash+zenity pour se faciliter la compil (style un champ ou tu tape la liste des tex que tu veux compiler 10;11;15;19..etc)

Bonne journée

[djinn]

Salut jbreizh,

Du coup pour générer a coup sur la même page, je vois 2 options:
- stocker tout les choix qui ont été fait, pour les réinjecter dans l'exercice..... je ne vois pas l'interêt d'une telle solution vs le stockage du tex
- créer un générateur de nombre pseudo aléatoire qui recréé la même série avec le même paramètre, puis venir modifier tous les appels à random dans le code et prevoir un moyen de rentrer ta clef.

En fait, random est un tel générateur, pouvant être initialisé (avec une seed) de manière à créer une série spécifique de nombres pseudo-aléatoires. Toutes les fonctions aléatoires de pyromaths reposant sur une méthode ou une autre de random, pas besoin de stocker toutes les valeurs concernées: il suffit d'initialiser random une seule fois et de relancer exactement la même procédure.
C'est ce que fait le patch d'exemple ci-dessus, en initialisant random au démarrage de l'application (sur option de la ligne de commande). Ce qui permet de fait de générer deux fois le même exercice (avec les mêmes valeurs, etc) en lançant deux fois pyromaths avec la même seed.

Perso, ce que je ferais:
- modification de vignette.py (le fichier que l'on utilise pour créé les vignettes) pour qu'il me fasse mes sujets et corrigés en boucle avec un nom itératif style sujet{numero}-eleve{numero}-sujet.tex
- stockage de tous ces tex dans un dossier au nom du sujet
- un petit script bash+zenity pour se faciliter la compil (style un champ ou tu tape la liste des tex que tu veux compiler 10;11;15;19..etc)

Merci pour ta proposition, je vais la creuser (je ne connais pas encore vignette.py, mal zenity…).

[jbreizh]

hello,
C'est intéressant, je ne savais pas que l'on pouvait faire ça (je vais me coucher moins c**).Après je ne suis pas confronté à ta problèmatique, mais je vois aucune objection que tu bosses dans ce sens (genre le mec qui se prend pour dieu ).
Bonne fin de we (même si pour moi c'est déjà fini )

[Jérôme]

Ça me semble un peu ambitieux comme projet pour un intérêt assez limité. Je pense qu'un coup de tar+bz2 sur les fichiers tex d'une promo donnée devrait faire l'affaire plutôt bien. Il faudrait alors juste un script qui puisse passer les noms, prénoms et classes aux fichiers générés par pyromaths, un peu dans l'esprit de ce qui existe pour pyromaths en ligne.

[djinn]

C'est vrai que présenté aussi brièvement, on doit avoir du mal à comprendre ma motivation. C'est ma faute: je voulais aller à l'essentiel.

Contexte: J'enseigne en bac+1 à des promos de 150 étudiants environ, et on fait des maths appliquées (à la finance) avec un niveau lycée: on introduit pas de nouveau concept. Les évaluations se passent la plupart du temps en amphi, avec mes seuls yeux pour surveiller.
L'an passé j'utilisais 2 à 3 sujets: pas assez pour éradiquer les opportunités de triche, mais suffisamment pour la mettre clairement en évidence: beaucoup de copies avec réponses qui eurent été les bonnes… avec le sujet du voisin!
Bref, la solution idéale serait: un sujet par étudiant. Mêmes exercices, mais dans un ordre aléatoire et avec des valeurs randomisées. Les sujets sont initialement anonymes (les étudiants inscrivent leur noms), et un numéro d'identification permet de retrouver la correction correspondante. Quitte à utiliser un numéro d'identification, autant qu'il ait également un sens (si possible): d'où l'idée d'utiliser la seed du générateur aléatoire.

Problème: Mais en réalité, mon problème c'est qu'il faut que je code chacun de ces exercices, et surtout leur correction -- qui demandera probablement plus d'efforts. Or, j'aimerais utiliser ces sujets dans quelques semaines. N'ayant jamais codé d'exercice pyromaths, je ne peux évaluer le temps qui me sera nécessaire et je crains naturellement d'en manquer… D'où l'idée de pouvoir re-générer une fiche d'exercice à partir de sa "seed": cela me permettrait de coder la correction ultérieurement, si le temps venait en effet à manquer.
La solution qui semble faire consensus (générer l'ensemble des fiches et corrections, les archiver, et faciliter leur manip avec Zenity par exemple) serait sans doute la meilleure si j'utilisais des exercices existants; Ou si j'avais déjà codé mes exercices et leurs corrections. Je comprends que, de ce point de vue, pouvoir re-générer une fiche (et/ou sa correction) à partir d'une "seed" apparaisse redondant.
Mon besoin personnel mis à part (beauté du libre: je n'ai pas besoin que le code que j'utilise soit in fine inclus dans pyromaths pour pouvoir l'utiliser), je pense néanmoins que cette seed peut présenter un intérêt un peu plus général, comme assurance ou comme "signature": cela pourrait permettre de re-générer les fichiers tex correspondant à un exemple papier en cas de perte de ces fichiers, par exemple…

Proposition: Ceci étant dit, peut m'importe que cette "fonctionnalité" soit incluse ou non dans pyromaths, et je suis ravi de laisser cette décision aux leaders du projet! Je reconnais également que, pris séparément, cela arrive comme un cheveu sur la soupe. Tout bien réfléchi, j'aurais dû commencer par autre chose. Du coup, dans l'idée de trouver des objectifs communs (et de rendre un peu de code au projet), je vais essayer de proposer quelque chose de plus général.
Une des solutions à mon problème de génération de multiples sujets consiste à externaliser la boucle (script bash par ex.), en utilisant pyromaths comme n'importe quelle autre commande UNIX. Ce qui implique un mode sans GUI, où les paramètres sont transmis via des options en ligne de commande.
Jusqu'ici, pyromaths s'utilise exclusivement via une interface graphique. Verriez-vous un intérêt à développer un mode "ligne de commande" pour pyromaths, dans la plus pure tradition UNIX?

[Jérôme]

Brièvement,

je ne suis pas favorable au seed, car cela signifie également qu'un étudiant peut générer le corrigé correspondant à son sujet.

Je maintiens (peut être à tort) que le plus simple est de générer l'ensemble des sujets, avec en titre le numéro du sujet. Ainsi, tu stockes les fichiers tex et en fonction du numéro du sujet, tu compiles/imprimes le corrigé qui t'intéresse.

D'un point de vue purement pratique, un inconvénient de ta méthode est le temps de correction. Tu ne finiras pas par connaître les réponses par coeur, ce qui t'aurait permis de gagner du temps de correction.

Enfin, pour une utilisation en ligne de commandes, je crois que c'est plus ou moins ce qui se fait avec Pyromaths en ligne. Mais ça peut très nettement s'améliorer, j'en suis bien convaincu.

Le plus urgent dans ce que tu racontes, c'est tout de même d'écrire de nouveaux exercices et des corrigés. Et ça, je suis preneur !

[djinn]

je ne suis pas favorable au seed, car cela signifie également qu'un étudiant peut générer le corrigé correspondant à son sujet.

C'est vrai dans le cas littéral: la seed est écrite sur la copie. Et c'est en effet ce que j'ai suggéré, pour simplifier mon explication. Mais, dans le détail, ce ne serait pas vrai.
Pour générer une série de sujets, on utilise une "seed" principale, tirée au sort sur un très grand intervalle; Cette "seed" principale reste secrète. Ensuite on numérote les copies de 0 à n, ce numéro représentant l'ID publique de la copie. Enfin on combine ID et seed principale (en les ajoutant par exemple) pour constituer le nombre qui initialisera in fine pyromaths:

Code: Tout sélectionner

pyromaths(seed+ID) => produit le sujet identifié par ID

En conclusion: on profite de tout l'intervalle possible pour initialiser random, on réduit l'ID d'une copie au minimum (2-3 chiffres), et on maintient l'asymétrie grâce au secret de la seed principale (l'élève ne peut pas générer sa correction).

Je maintiens (peut être à tort) que le plus simple est de générer l'ensemble des sujets, avec en titre le numéro du sujet. Ainsi, tu stockes les fichiers tex et en fonction du numéro du sujet, tu compiles/imprimes le corrigé qui t'intéresse.

Quand on peut le faire (notamment imprimer le corrigé en même temps), ce qui est le cas normal pour un utilisateur de pyromaths, je suis d'accord: jouer avec les seed n'est pas nécessaire.
Le principal intérêt que j'y verrais, je pense, vaut principalement pour les développeurs d'exercices, dans la mesure où ça permet de coder énoncés et corrections séparément. Dans mon cas, les énoncés ne sont que de simples phrases alors que les corrections contiennent des équations, etc: j'imagine que ça change tout en temps de programmation… Je me suis naïvement dit: étant donné que ça pourrait m'être utile, peut-être que ça pourrait servir à d'autres, voire à d'autres choses? Pour autant, si tu juges que ça ne justifie pas d'être inclus dans pyromaths, ça ne me dérange absolument pas.

D'un point de vue purement pratique, un inconvénient de ta méthode est le temps de correction. Tu ne finiras pas par connaître les réponses par coeur, ce qui t'aurait permis de gagner du temps de correction.

Tu as tout à fait raison: c'est le prix à payer pour ce type d'évaluation. D'où l'idée d'assister le processus au maximum: je prends la copie, je tape 3 chiffres, la correction s'affiche à l'écran, elle s'imprime pendant que je corrige et note la copie, j’agrafe copie et correction, je pose la copie.
Pour tout dire, c'est vraiment un test: il est fort possible que j'en revienne échaudé! À suivre…

Enfin, pour une utilisation en ligne de commandes, je crois que c'est plus ou moins ce qui se fait avec Pyromaths en ligne. Mais ça peut très nettement s'améliorer, j'en suis bien convaincu.

Pyromaths en ligne?

Le plus urgent dans ce que tu racontes, c'est tout de même d'écrire de nouveaux exercices et des corrigés. Et ça, je suis preneur !

Si j'arrive à quelque chose qui t'intéresses, ce sera avec plaisir.
À ton avis, il faut combien de temps approximativement pour traduire un exercice existant en exercice pyromaths?