Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problème : DECODE et la mystérieuse fonction six_voeu_L1 #17

Open
GuillaumeTara opened this issue Oct 19, 2016 · 17 comments
Open

Problème : DECODE et la mystérieuse fonction six_voeu_L1 #17

GuillaumeTara opened this issue Oct 19, 2016 · 17 comments

Comments

@GuillaumeTara
Copy link
Collaborator

Hello,

Je viens vers vous avec une question qui est assez cruciale dans l'algorithme...

Ligne 102 on a un DECODE(l_six_voe, 1, six_voeu_L1(c.g_cn_cod, g_aa_cod_bac_int, g_cn_flg_int_aca, o_g_tg_cod), 0) qui est le deuxième attribut du select.

En gros, on nous génère un booléen. Derrière, dans le order by il y a "ORDER BY 2 desc" (ligne 149). EN gros, ce booléen est discriminant puisqu'il va placer les candidats ayant un 1 dans tous les cas avant ceux qui ont un 0, quel que soit l'ordre de leur voeu.

Mais comment comprendre ce Decode ?

D'après la doc que j'ai pu lire, on va effectuer ces étapes :
IF l_six_voe == 1
THEN RETURN six_voeu_L1(c.g_cn_cod, g_aa_cod_bac_int, g_cn_flg_int_aca, o_g_tg_cod)
ELSE RETURN 0

Dans un premier temps, j'avais cru que ce booléen représentait le critère d'appartenance à l'académie du candidat. Car normalement la règle d'APB veut que les candidats de l'académie soient prioritaires.

Or, ici, en regardant le nom des variables et après une discussion avec une journaliste éduc à l'étudiant il semblerait plutôt qu'on soit en train de vérifier si les candidats ont bien rempli les 6 voeux. Car, en effet, en île de france les candidats doivent avoir rempli 6 voeux en licence.

Mais ce serait bizarre pour 2 raisons :
(i) Cette règle ne s'applique qu'aux candidats de l'ile de France
(ii) A quel moment dans le code vérifie-t-on le critère académique ? Parce qu'à aucun autre endroit dans les classements on ne semble checker si le candidat habite dans l'académie de la formation. Or, si c'est le cas il devrait être avantagé dans les classements.

Pour bien comprendre ce qui se passe, il nous manque le code de la fonction six_voeu_L1, j'en conviens.

Mais si on part du principe qu'on vérifie le critère des 6 licences, cela voudrait dire que le code fournit par APB ne correspond qu'aux licences d'IDF.... A moins que je ne sois passé à côté du critère géographique.

Qu'en pensez-vous ? Si vous avez des pistes d'éclairage, je suis preneur...

@AxelVoitier
Copy link

AxelVoitier commented Oct 19, 2016

Je l'interprete comme :
Si l_six_voe == 1 Alors cette colonne prend la valeur retournee par la mysterieuse fonction six_voeu_L1(). Sinon, la colonne prend la valeur 0.
https://www.techonthenet.com/oracle/functions/decode.php

Mais rien ne dit que c'est un booleen (en tout cas pas d'apres juste les requetes, j'ai pas encore regarde le reste du code).

@GuillaumeTara
Copy link
Collaborator Author

Effectivement... depuis le début dans ma tête c'est un booléen, mais en fait si ça se trouve pas du tout... Il nous manque cette fonction six_voeu_L1 qui n'a pas été fournie par le Ministère.

@AxelVoitier
Copy link

AxelVoitier commented Oct 19, 2016

Autre chose que je viens de voir, lignes 172 a 186, a propos de la variable l_six_voe :
-- On vérifie si le groupe est issu d''une formation de type IDF 2, 3, 5 ou 6 et s'il concerné par des néo d'IDF -- alors, on utilisera les six voeux dans le classement sur ordre des voeux

Et plus loin :
-- pour les autres groupes, on n'utilise pas les 6 voeux

@GuillaumeTara
Copy link
Collaborator Author

Bizarre, bizarre... ça ferait une redondance avec le decode cette phase, non ?

@AxelVoitier
Copy link

Bah, cette phase prepare la variable l_six_voe pour le decode.
Les curseurs ont beau etre declare avant, si je me souviens bien les variables sont evaluees quand le curseur est execute, ce qui arrive apres la definition de l_six_voe par cette phase.

@GuillaumeTara
Copy link
Collaborator Author

aaaaaaaaaah ! Du coup l_six_voeu prend la valeur 1 si on est en type IDF 2,3,5,6 et 0 sinon, pour les autres groupes.

Mais du coup ça signifie que dans le decode, si un candidat est IDF 2,3,5,6 alors on va retourner la valeur de la fonction six_voeux_l1 et sinon on renvoie la valeur 0. Ce qui signifierait, pour le coup, que les candidats hors IDF sont par défaut désavantagés ?..

Plus je comprends, moins c'est clair :'(

@AxelVoitier
Copy link

AxelVoitier commented Oct 19, 2016

C'est ce que je pensais au debut mais je n'en suis plus si sur.
Parce que cette variable l_six_voe depend de la formation et non du candidat. Donc si le candidat est en IDF et demande une formation en IDF il a sa preference academique. Et pour les autres candidats non IDF qui demandent une formation IDF ils passent apres les candidats IDF.

Ce qui semble etre l'effet voulu si je comprend bien.

@GuillaumeTara
Copy link
Collaborator Author

Ah je comprends. Quand ils disent "on vérifie si le code est issu d'une formation de type IDF", c'est qu'ils regardent si on est en ile de France. Si tel est le cas, l_six_voe prend la valeur 1 et du coup dans le Decode on ira appeler la fonction pour vérifier l'appartenance géographique et le critère des 6 voeux.
Mais si ça n'est pas le cas, que la formation n'est pas en ile de france, l_six_voe prend la valeur 0, du coup on n'appellera pas la fonction pour les candidats mais ils auront tous les valeur 0 pour leur premier attribut de classement.

Mais du coup c'est comme si la vérification d l'académie n'était faite que pour les formations en IDF et pas pour les formations or IDF. C'est bizarre... Ou alors je n'ai pas compris.

@Sboulahia
Copy link

Sboulahia commented Oct 20, 2016

Les seules licences non sélectives à capacité limitée sont en Île-de-France.

D'après les rumeurs qui couraient à propos d'APB, les bacheliers de l'académie de l'université en question seraient prioritaires sur les bacheliers IDF qui seraient eux-mêmes prioritaires sur les autres.

L'argument g_cn_flg_int_aca est sans doute l'académie du candidat.
Il reste à savoir ce qu'est g_aa_cod_bac_int et pourquoi la fonction aurait besoin de prendre en argument à la fois g_cn_cod et g_cn_flg_int_aca alors que, quoi que fasse la fonction, un seul des deux arguments suffirait. A moins que la fonction traite le numéro du candidat en tant que tel ? ^^

@GuillaumeTara
Copy link
Collaborator Author

A priori ça ne devrait pas être appliqué qu'en île de france :
"Bien que non sélectives, certaines licences (L1) sont en « tension », c’est-à-dire que le nombre de candidats est supérieur au nombre de places (sur le site APB, elles sont indiquées par la mention « Licence à capacité limitée »). Cela concerne les doubles cursus, ou encore les filières STAPS, Droit, Santé, Psycho particulièrement en Île-de-France, mais aussi parfois dans d’autres régions. Pour augmenter vos chances d'accéder à ces filières, vous devez faire un voeu unique. Par exemple, vous pouvez demander toutes les formations en Droit de votre académie. Sachez que l'île-de-France, qui comprend les académies de Créteil, Paris et Versailles, est considérée comme une seule et même zone pour ces voeux uniques. "

@Sboulahia
Copy link

Au temps pour moi. Les formations non sélectives à capacité limitée sont peut-être toutes considérées comme de type "IDF".

Que signifie "vœu unique" ? Les prioritaires ne sont pas supposés être ceux qui ont formulé 6 vœux ou plus ?

@khena
Copy link
Collaborator

khena commented Oct 22, 2016

je pense que nous sommes tous d'accord, l_six_voe est un boolean, c'est confirmé par le test et par le code en X2 l_six_voe dépend du paramètre o_g_tg_cod , qui est lui même repassé à la fonction mystère.

Donc pour reprendre tout ce qui a été dit, voilà ce que fait la fonction DECODE

J'ai trouvé les champs dans le modèle https://drive.google.com/drive/folders/0B6a96AZlutX9RjRZLWxySjYxUVU

g_cn_flg_int_aca est de type NUMBER(1) et ne correspond pas à une clé étrangère
@Sboulahia pour moi ce n'est pas l'académie du candidat, sinon ça serait un CODE (et une clé étrangère) et , on retrouverait le mot "_cod" comme les autres. Le flg me fait plutôt penser à "flag",genre c'est un booléen, ce qui correspondrait à un petit number. De ce que je peux voir dans le modèle, ça semble être bien un boolean.

G_AA_COD_BAC_INT est de type NUMBER(3) et ne correspond pas à une clé étrangère
Par contre, on trouve trace de G_AA_COD dans d'autres tables

Cette fonction n'a absolument aucun sens :
Comme le dit @Sboulahia , pourquoi passer le code du candidat si le candidat n'a qu'un seul g_cn_flg_int_aca et qu'un seul G_AA_COD_BAC_INT possibles ?

La seule justification serait que la fonction mystère fasse une requête SQL avec le candiat et ces deux paramètres sur l'Ile de France.

Encore une fois, tout ça suppose que le modèle est correct et qu'il y a bien des clés étrangères partout.

Enfin bref, ça semble correspondre à la description de priorité que cite @GuillaumeTara.

SI le groupe est issu d''une formation de type IDF 2 à 6 et s'il concerné par des néo d'IDF
ALORS retourne probablement 1 pour être devant les autres
En paramètres de la fonction mystère :
- du code du candidat
- g_cn_flg_int_aca
- G_AA_COD_BAC_INT
- o_g_tg_cod < forcément un groupe IDF 2-6 ET néo IDF

SINON retourne 0 (et le candidat se retrouve à la fin)

Attention, (roulement de tambour) voilà ma déduction :

La fonction mystère six_voeu_L1 permet de savoir si le candidat a fait un voeux unique pour l'académie IDF. Elle a besoin des trois paramètres car elle ne fait pas appel directement à la table candidat.

@jferard
Copy link
Collaborator

jferard commented Oct 22, 2016

J'en arrive à la même conclusion que @khena.

Le booléen l_six_voe est vrai seulement si NVL(g_ti_flg_rec_idf, 0) IN (2, 3, 5, 6), ce qui veut dire que la formation a le flag IDF. Donc on dirait bien que ce sont les formations IDF qui sont concernées par la fonction. Mais peut-être était-ce le cas seulement à l'origine, et qu'on peut maintenant avoir des formations en tension d'autres régions qui sont flaggées IDF.

J'en viens à la fonction six_voeu_L1. A priori, on peut avoir deux types de fonctions dans ce cas (j'écarte les fonctions à effets de bord) :

  1. une fonction qui prend une valeur arithmétique, ex. f(x, y, z) = y si x > 0 et z si x <= 0 (dans cette fonction, x joue le rôle de flag).
  2. une fonction qui prend une valeur tirée de la base, avec un SELECT ... WHERE et des conditions sur les paramètres.

Si je compare les arguments passés à la fonction, soit c.g_cn_cod, g_aa_cod_bac_int, g_cn_flg_int_aca et o_g_tg_cod, aux tables de https://drive.google.com/drive/folders/0B6a96AZlutX9RjRZLWxySjYxUVU, on retrouve le code candidat (g_cn_cod) dans plusieurs tables, ce qui est normal. Mais les autres g_aa_cod_bac_int, g_cn_flg_int_aca ne se retrouvent que dans la table des candidats. Enfin, g_tg_cod n'apparaît dans aucune table.
Il est normal qu'un flag ne soit comparé qu'à 0 ou 1, et on remarque ligne 181 que o_g_tg_cod est comparé à des "magic numbers". Il reste donc le code candidat et g_aa_cod_bac_int pour faire une jointure. En même temps, comme le dit @khena, ce champ g_aa_cod_bac_int n'est pas une clé étrangère. Donc il devrait être comparé également à des valeurs constantes.

Il ne reste que le code du candidat pour une sélection dans une table. Comme le dit @khena, il doit servir à une requête, et probablement une requête sur la table des voeux.
Je reconstitue donc la requête mystère (à supposer qu'il s'agit bien d'une requête) comme ceci :

SELECT ???
FROM a_voe v
WHERE v.g_cn_cod = g_cn_cod -- c'est le candidat cherché 
AND g_cn_flg_int_aca = 1 AND o_g_tg_cod IN (...) AND g_aa_cod_bac_int IN (...)

o_g_tg_cod pourraît être le type de formation (Droit, Psycho, etc.).

Il est possible que ce SELECT retourne un nombre de lignes (SELECT COUNT(*)). Je penche la version de @khena : si le SELECT COUNT(*) renvoie 6, c'est que le candidat à fait un voeu unique, par ex. que du Droit (o_g_tg_cod), pour différents établissements. Alors la fonction retourne une valeur > 0, ce qui permet au candidat d'être prioritaire comme expliqué dans la citation de @GuillaumeTara.

Si tout cela est juste, pourquoi ici cet appel de fonction alors que le reste du script utilise des techniques type SELECT INTO ou IF et une variable locale ?

@khena
Copy link
Collaborator

khena commented Oct 25, 2016

Bon les amis, si j'en crois la déclaration du ministère sur le site du monde (merci à @GuillaumeTara pour le retweet) : http://www.lemonde.fr/campus/article/2016/10/25/apb-les-questions-que-souleve-le-code-source_5020076_4401467.html

Le ministère explique avoir « effectué des vérifications » sur cet aspect, « l’équipe de développeurs de l’INP Toulouse [en charge d’APB] a fait des simulations, etc. ». Résultat : « Il n’y a absolument pas de bug. Le classement binaire utilisé fait qu’il n’y a aucun souci », et que ceux qui n’ont pas « classé » une formation n’y sont donc naturellement pas prioritaires, plaide-t-il.

On parle bien de classement binaire, 1 puis 0 .

@Sboulahia
Copy link

Bonjour,

La fonction mystère six_voeu_L1 permet de savoir si le candidat a fait un voeux unique pour l'académie IDF. Elle a besoin des trois paramètres car elle ne fait pas appel directement à la table candidat.

La deuxième phrase est plausible. Par contre APB donne entre autres la priorité aux étudiants qui ont postulé pour au moins 6 licences, d'où le nom de la fonction et c'est indiqué en clair aux candidats lors de leur procédure. Cela n'est donc pas possible que la fonction Six_voeu_L1 est une fonction booléenne qui indique est-ce que le candidat a fait un vœu unique. On sait au moins que cette fonction renvoie un nombre supérieur si le candidat en question a postulé pour + de 6 licences.

@khena
Copy link
Collaborator

khena commented Oct 25, 2016

D'après l'explication du ministère, je pense que la fonction renvoie 1 si le candidat a opté pour + de 6 licences :)

@jferard
Copy link
Collaborator

jferard commented Oct 25, 2016

@khena Peut-être une confirmation sur ce point, tirée du document http://cache.media.enseignementsup-recherche.gouv.fr/file/orientation-insertion_professionnelle/44/5/rapport-apb-oct2012_239445.pdf mentionné par @haplorhinien ailleurs (#26) : p. 16, il est expliqué que :

Les candidats à une L1 de ce type [à capacité insuffisante] sont retenus par un algorithme dont les principales règles sont les suivantes :

  • sont d’abord classés les candidats ayant sollicité au moins six voeux de L1 ; un premier groupe G1 est
    ainsi constitué ;
  • puis ceux ayant classé cette L1 en premier voeu de la formation concernée (premier voeu relatif à cette
    formation par rapport à l’ensemble des voeux formulés par le candidat) ; ils constituent alors un groupe
    G2 (inclus dans G1) ;
  • puis les candidats ayant sollicité cette L1 en voeu 1 absolu (première position par rapport à l’ensemble
    des voeux formulés par le candidat) ; ils forment alors un groupe G3 (inclus dans G2) ;
  • si la capacité d’accueil n’est pas suffisante pour accueillir tous les étudiants, le choix se fait par tirage au
    sort d’abord au sein de G3, puis éventuellement en faisant appel à G2 puis G1.

Conclusion probable : l_six_voe vaut 1 si la licence est a capacité limitée ; la fonction six_voeu_L1 renvoie 1 si le candidat a opté pour au moins 6 licences.

Pour être prudent, je formulerai ainsi : l_six_voe devrait valoir 1 si la licence est a capacité limitée ; la fonction six_voeu_L1 devrait renvoyer 1 si le candidat a opté pour au moins 6 licences.

Mais tant qu'on n'a pas l'explication des magic numbers et la manière dont ils sont affectés aux formations, ni vu le code de la fonction, on en est réduit à faire confiance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants