Merci pour ce rapport détaillé !

1 seul coeur travaille à la fois.

C'est bizarre : les 4 cœurs devraient être sollicités lors de certaines tâches (comme l'analyse par exemple). Avez-vous fait un réglage spécial dans Edition/Préférences/Système ? Utilisez-vous une virtualisation qui limite l'usage des processeurs ?

Je comprend mal pourquoi Le "Corriger" met 19 minutes.

Je ne comprends pas non plus... Avez-vous observé quelque chose de particulier pendant cette correction ? Du swap ? Si vous l'effectuez en ayant lancé AMC en ligne de commande (auto-multiple-choice), y a-t-il des sorties particulières dans la console ?

J'utilise fédora16 sans virtualisation.

En effet, les 4 cœurs sont utilisés durant la phase analyse mais pas durant la phase correction.
Dans Edition/Préférences/Système
J'avais laissé le paramètre par défaut:0
En passant à 4, les performances ne changent pas.

En lançant en ligne de commande.
A l'ouverture de mon projet, j'ai:
Use of uninitialized value $both in concatenation (.) or string at /usr/lib/AMC/perl/AMC-gui.pl line 3621.
Rien à la saisie des copies
Rien à la correction

La vitesse de correction n'est pas linéaire. A partir de la barre de progression:"calcul des notes", j'ai fait les relevés suivants:
Progres.copies..temps...temps.copies/s
%...............nb.......s..........%.......
0,00.........0,00......0,00......0,00......?
13,30.......85,11....10,00...0,86....8,51
21,28......136,17..37,00...3,19....1,89
31,91......204,26..90,00...7,76....1,28
54,26......347,23..323,00..27,84...0,61
61,17......391,49..430,00..37,07...0,41
66,49......425,53..510,00..43,97...0,43
79,79......510,64..740,00..63,79...0,37
86,70......554,89..870,00..75,00...0,34
95,21......609,36..1050,00.90,52...0,30
100,00.....640,00..1160,00.100,00..0,28

Est-ce que le fait d'utiliser plusieurs fois les mêmes copies avec les mêmes numéros de candidat peut avoir une influence?
Je peux fournir les sources pour analyse si nécessaire.

A partir de la barre de progression:"calcul des notes", j'ai fait les relevés suivants:

La case "Mettre à jour le barème" était-elle cochée ou non ?

Je peux fournir les sources pour analyse si nécessaire.

Je veux bien, merci !

La case mettre à jour les barèmes était cochée.

Merci de m'envoyer un mot de passe par mail.
Il sera nécessaire pour le téléchargement de l'archive: je ne souhaite pas rendre publique les copies de mes élèves.

Merci pour vos envois. Je crois que j'ai enfin réussi à identifier la source de cette non-linéarité problématique.
La révision hg:de246dd9e50a devrait régler le problème.

Merci pour l'upgrade.
Dans cette nouvelle version, c'est l'affichage du temps qui devient linaire ou la vitesse d’exécution qui est augmentée?

C'est la vitesse d'exécution qui est augmentée : elle est maintenant proportionnelle au nombre de copies à corriger, alors qu'elle était quadratique avant (sans raison). J'ai ajouté un index à la base de données pour que l'accès aux barèmes soit plus rapide.

Le test avec la version hg:de246dd9e50a sur le même paquet de copies donne:
Analyse: 5min10s
Corriger: 14 seconde
1 seul cœur travaille pour la phase corriger mais c'est largement suffisant!

Idée (ça serait plutôt une "feature request"):
Est-il envisagé de faire de la reconnaissance de caractère dans une version future.
Ça parait plus facilement envisageable sur no de candidat+nom+prénom car on peut comparer à la base pour détecter/corriger les erreurs.

Est-il envisagé de faire de la reconnaissance de caractère dans une version future.

C'est vrai que ça serait bien pour le numéro d'étudiant, mais je n'ai pas trop l'expérience de ça, alors je ne m'y suis pas attelé pour l'instant... (avis aux amateurs !)

Voici un rapide rapport du déroulement du QCM avec les 634 étudiants réels présents
Conditions du QCM
Feuille de ré séparée, une réponse numérique, 44 question ou questions multiples de 3 à 4 réponses. Les étudiants sont répartis dans 17 salles ou amphis.
Les QCM sont tous identique (pas de mélange).

Conditions de scan
Par paquets de 4 groupes=100 feuilles A4
Temps de scan: 2min par paquet et 2 min entre les paquets
Scan en 200 dpi noir et blanc pdf

Reconnaissance des cases cochées
6 minutes
Intervention manuelle sur 21 copies=3% pour corriger la reconnaissance(principalement effaceur ou blanc+reconstruction)
Reconnaissance des étudiants dans la base
10 étudiants n'ont pas été reconnus (1.6%) car leur numéro était pas ou mal coché. Je pense que c'est une performance mais on avait fait très attention à ce point(consignes aux surveillants).

Calcul des notes:
10 seconde (avec la modification hg:de246dd9e50a)
Export libre office toutes options cochées
2 minutes

Annotation des copies
Très long (plus de 30 minutes)
Option un fichier pour tous les étudiants
Composer décoché
Seuls les jpg sont générés, pas de pdf. Le pdf est généré uniquement si composer est coché mais ce n'est pas ce que je veux.

Post traitement:
Comparaison du taux de fraude par salle et analyse individuelle.
J'ai fait un post traitement sur excel des cases cochées.
Toutes les copies ont été croisées 2 à 2 pour trouver le nombre de réponse identiques.
Grâce aux max(nb réponses identiques), on retrouve les copies très proches(pire cas: 98% de réponses identiques, 95% de réponses fausses identiques=19 questions).
Grâce aux moyennes(max(nb réponses identiques))), on trouve la copie moyenne par salle. Je retrouve une moyenne plus élevées là ou les tables sont plus proches...
Est-ce que ça intéresse d'autres d'intégrer cette fonctionnalité à AMC?
Si oui, je peux transmettre ma méthode de travail. Elle peut être optimisée par quelqu'un qui a de sérieuse connaissances en statistique(nombreux biais possibles si analyse mal conduite...).

Merci pour ce retour d'expérience.

(principalement effaceur ou blanc+reconstruction)

Je donne en effet la consigne de ne surtout pas reconstruire la case si on emploie du blanc.

max(nb réponses identiques)

Ces indicateurs sont intéressants ! Le choix de ne pas utiliser de mélange est-il dû à des raisons pédagogiques ou pratiques ?

Nous n'avons pas fait de mélange pour raison pratique:
- Nous ne voulions pas prendre de risque pour cette première expérience à grande échelle
- La correction manuelle reste possible
- L'impression se fait en offset pour 640 copies

Comme le test est un succès, nous allons mélanger l'année prochaine. J'essaye de pousser vers 640 copies différentes mais les difficultés d'impression nous pousseront certainement vers 5 à 10 sujets différents...

perso pour l'impression je pense que l'offset n'est pas un soucis l'utilisation d'un seul et unique fichier pdf permet une impression de copie differente en 1 fois

je pratique cette methode pour mes controles ce qui à un resultat pas trop mal

Bonjour,

Déterrage de ce vieux post...
Si au lieu de scanner en pdf, le scan se fait en couleur, la phase conversion de pdf vers bipmap dure beaucoup plus longtemps que la saisie et se fait en simple coeur.
Par exemple: 3 minutes de conversion pour 30s de saisie.

Évidement, une solution simple est de scanner en noir et blanc mais le scan couleur permet de mieux corriger les défauts...
Une autre solution consisterais à scanner en jpg mais je ne sais pas si une conversion est encore nécessaire...

Je suis maintenant à la version 1.2.1

Benoît

Une autre solution consisterais à scanner en jpg mais je ne sais pas si une conversion est encore nécessaire...

Il me semble que ce serait plus efficace en effet, car la première chose que fait AMC quand on lui donne des fichiers PDF est d'en extraire les images sous forme de fichiers bitmap.

Nouvelles performances sur 697 copies pour cette année
Le processeur est un i3-2100 4 coeurs à 3.1GHz
Ubuntu 16.04LTS
AMC 1.2.1

Les sujets sont en A3 recto-verso
800 sujets différents avec mélange des questions, des réponses, des valeurs numériques aléatoires placées dans des figures du texte, des réponses numériques variables et figures variables.
Les copies sont scannées en jpg 200x200 dpi en recto puis verso par paquets de 75 (plus rapide que le scan recto-verso). Environ 1h de travail sur le photocopieur.
Taille des jpg: 1.2Go

Reconnaissance des cases cochées
14 min30-4 cœurs travaillent
Calcul des notes
4 minutes29s
un seul coeur travaille
Annotation des copies
48 min 18 s -4 cœurs travaillent
Ouverture du fichier
47s
Effacer 1394 pages
1min5s
Taille du dossier une fois toutes les opérations réalisées
6 Go

Le calcul des notes est devenu très long. Très certainement à cause des 800 sujets différents.
Je travaille au départ sur un échantillon de 75 copies pour affiner les paramètres des onglets scan et affichage.
J'affine ensuite le barème toujours sur 75 copies.

• Utilisation des 4 cœurs
• Ne calculer les notes que des copies réellement utilisées

Je peux fournir un dossier pour test si nécessaire.

Merci pour votre retour !

Le temps de calcul des notes est très long même avec 75 copies. C'est assez pénalisant car il faut faire de nombreux essais.

Pouvez-vous mesurer le temps passé à extraire le barème et celui passé à calculer les notes ?
L'extraction du barème consiste à compiler le sujet avec LaTeX : on ne peut pas le paralléliser et je n'ai pas trouvé de méthode pour faire gagner du temps à LaTeX en lui disant de ne pas fabriquer de fichier PDF…

La correction se passe en 3 étapes avec le détail de la sortie des commandes activé.

Pour 75 copies sur 800:
Analyse du baréme=making marks scale(affichage fixe):3min56
Analyse du baréme=défilement de sheet45/bareme=0.00.../sheet46/bareme=...:12s
Calcul des notes=notation(defilement):3s
J'ai fait une vidéo de cette étape si nécessaire.

Si je comprend bien, pour une simple mise à jour du barème:
Il est nécessaire de compiler avec Latex. Cette compilation fourni à la fois le pdf et le barème
Comment est faite techniquement cette étape? Je doute d'arriver à trouver une solution mais ça m'intéresse.

Si je comprend bien, pour une simple mise à jour du barème: il est nécessaire de compiler avec Latex.

Exactement. Et c'est cela qui prend du temps, surtout si vous faites faire à LaTeX des calculs mathématiques.
Lors de la compilation, LaTeX va simplement écrire dans un fichier à part les informations concernant le barème. On est obligés de passer par là pour laisser la possibilité d'utiliser des macros LaTeX pour spécifier un barème, et aussi de gérer des données numériques aléatoires à partir de LaTeX (qui mèneront à des bonnes réponses différentes suivant les copies).

Bonjour,

Je me permets de déterrer ce sujet car j'ai le même problème que mentionné plus haut : pour 75 copies, il me faut plusieurs longues minutes pour corriger... et il me faut souvent plusieurs tentatives pour parvenir à une version de barème qui me satisfasse. Au moins j'ai compris l'origine du problème.

Ma question est donc : à défaut d'une actualisation du barême général, un ajustement global tel que \bareme{SUF=30} (pour simplement ajuster le nombre de points à obtenir pour obtenir 20/20) peut-il être fait sans recompilation ? En éditant un fichier texte quelque part ?

Question subsidiaire : j'utilise beaucoup de questions ouvertes avec un barème du type :

\newcommand{\baremeOuverte}[2][1]{
  \pgfkeys{/baremeOuverte/.cd,%
    choices/.store in=\choicesKey,% Nombre cases
    choices=2,%
    total/.store in=\totalKey,% Score total (coefficient)
    total=1,%
    text/.store in=\AMCotextReserved,% Texte zone à cocher
    text=\emph{Réservé},%
  }%
  \pgfkeys{/baremeOuverte/.cd,#1}%
  \bareme{
    e=0,% incohérence (2 réponses cochées)
    v=0,% absence de réponse cochée
    MAX=\totalKey,% Nombre de points de la question
    default.POINT=0,% Pas de case cochée 0 pt
    formula=(\totalKey *POINT/(N-1))% La ième case cochée rapporte (i-1)/(n-1)
  }%
  \pgfmathsetmacro{\fin}{\choicesKey - 1}
  \AMCOpen{#2}{
    \foreach \i in {0,...,\fin}%
    {
      \mauvaise{\i~}\bareme{set.POINT=\i}%
    }%
    \bonne{\choicesKey~}\bareme{set.POINT=\choicesKey}%
  }%
}

(voir ici : Exemples_d'utilisation_en_coll%C3%A8ge)

Cela serait-il un facteur aggravant pour le temps de calcul ?

Merci pour votre aide.

Bonjour,

Je sais pas vraiment répondre sur ce qui permet de corriger plus vite ou moins vite.
En pratique, pour comparer 2 contenu, je fais un test et je chronomètre... Certaines solutions sont beaucoup plus rapides que d'autres.
Si c'est possible, il faut agir sur le matériel: processeur, disque et système.
On a pas toujours le choix, mais si c'est possible, lire ci-dessous.

• Voir https://project.auto-multiple-choice.net/boards/4/topics/3335
• Utiliser un ssd et mettre le projet amc qcm sur le disque système
• Privilégier moins de cœurs plus performants que plus de cœurs car un seul fonctionne à la notation
• Ne pas travailler sur le réseau
• On peut virtualiser mais il faut plus de puissance et bien configurer.

Voila des test de performance mis à jour pour se faire une idée.

• i3-2100(3éme génération):1567/3597 (cité plus haut)
• i7-3770(3éme génération):2073/9460
• i7-9850H(9éme génération):2563/11541

• Celeron N4020: 1191/1615
  Bien moins bien que mon i3-2100 de 2010 !

Pour 100€, un pc fixe sur le bon coin avec i7-3770...
A noter: on peut faire beaucoup mieux dans le neuf à 500€, j'ai volontairement choisi un mauvias exemple.

Détail des tests:

• Config 1: Linux 20.04lts natif i7 3770+8Go Ram(en 2013 à 300$-65€ sur ebay aujourd'hui)
• Config 2: Ubuntu20.04lts dans virtualbox -1 processeur sur 12 -8Go/16Go-100% ressources allouées(i7-9850H 395$ neuf)
• Config 3: Ubuntu20.04lts dans virtualbox -6 processeur sur 12 -8Go/16Go-100% ressources allouées (i7-9850H)

• config 1:17min50s
• config2: 6min50s
• config3: 4min30s

• config1:3min50s
• config2:8min10s
• config3:2min30s