Skip to content

Latest commit

 

History

History
54 lines (43 loc) · 8.06 KB

J-Voting.adoc

File metadata and controls

54 lines (43 loc) · 8.06 KB
Raw

J-Voting

Application de manipulation et visualisation de données de vote

Contexte

La théorie du choix social étudie les propriétés et mises en œuvre de méthodes de vote variées. Une méthode de vote, dans ce contexte, est une façon d’agréger les préférences des électeurs de façon à en déduire une préférence de la société (un choix, ou un rangement, typiquement). Ce projet a pour but de permettre la visualisation de données d’élections, de les manipuler, et de tester des méthodes.

Il s’agira d’améliorer et étendre un projet actuellement utilisé comme base pour des articles de recherche. Le projet permet la manipulation de préférences de base et l’édition de certaines formes de préférence, ainsi que l’import depuis une feuille de calcul et depuis des formats standards.

Documentation

Dans ce projet, un ensemble de candidats, d’objets, appelés alternatives, est envisagé pour un choix collectif. L’élection présidentielle en France en est un exemple, où les alternatives sont les candidats aux présidentielles. Le choix d’un restaurant entre un groupe d’amis est un autre exemple, où divers restaurants constitueront l’ensemble des alternatives. Un ensemble d’électeurs (voters en anglais) expriment leurs préférences sur cet ensemble d’alternatives. Contrairement à l’élection présidentielle, on envisage ici qu’on connait le classement de chaque électeur sur les alternatives. Ainsi, on sait que l’électeur 1 classe le candidat C avant le candidat B, lui-même avant le candidat D, et le candidat A en dernier, par exemple. Une règle de vote est une fonction associant à chaque ensemble de préférences (associées aux électeurs) un ou plusieurs gagnants ex-æquo.

Le projet doit permettre la manipulation de telles préférences, et leur aggrégation en vue de déterminer un vainqueur, en utilisant l’une des nombreuses règles de vote définies par les chercheurs en choix social.

Diverses restrictions peuvent s’appliquer sur les préférences exprimées par les électeurs : elles peuvent être complètes (pour chaque paire de candidat, on sait que l’un est au moins aussi bon que l’autre), anti-symétriques (pas d’ex-æquo), …

Pour représenter une préférence, on définit généralement une relation de préférence « au moins aussi bon que », considérée comme transitive (donc si A est au moins aussi bon que B, elle-même au moins aussi bonne que C, A est au moins aussi bon que C). Si un électeur juge le candidat A au moins aussi bon que B, et B au moins aussi bon que A, on dit que A et B sont ex-æquos (pour cet électeur). Si A est au moins aussi bon que B, et B n’est pas au moins aussi bon que A, on dit que A est strictement préféré à B (pour cet électeur, et dans le cas où la relation est entièrement connue). C’est ce genre de relation de préférence qu’on vise à manipuler ici.

À envisager

  • Améliorer si besoin la doc des formats de préférence pref lib supportés par ce projet, voir SOC, doc, exemple.

  • Export d’une préférence en ligne de commande : le programme lit preference.soc dans le répertoire courant (déplacer et améliorer méthode dans ReadProfile) et écrit la même préférence au format DOT (voir JGraphT adapter et éventuellement org.decision_deck.utils.relation.graph.GraphExporter et org.decision_deck.utils.relation.graph.mess.DOTExporterTemp<V, E>, dans J-MCDA utils)

  • Export similaire de DOT en SVG

  • Pouvoir indiquer une URL de PrefLib

  • Poursuivre l’implémentation du GUI d’édition d’un SOC, d’abord pour un seul électeur, comme planifié dans la doc

  • Permettre d’ouvrir le GUI en ligne de commande avec une URL d’un SOC ; le programme le télécharge et l’ouvre pour commencer l’édition

  • Préciser dans la doc : MutablePreference autorise toutes les modifications (ajout ou suppression d’arêtes et d’alternatives) ; MutableLinearPreference garantit que la préférence est linéaire

  • Javadoc warnings

  • Ajouter asStrictGraph() dans Preference, qui renvoie un graphe transitif, asymétrique, sous-graphe de asGraph, qui contient uniquement les paires (a, b) telles que a est strictement préféré à b (c-à-d telles que (a, b) est dans asGraph mais (b, a) n’y est pas).

  • Ajouter ImmutablePreference#equals

  • Changer MutableLinearPreference#addAlternative, removeAlternative et swap : lever une exception si les alternatives sont déjà ou ne sont pas déjà dans le graphe, empêchant la méthode d’effectuer l’action demandée

  • Ajouter MutableLinearEdges qui permet de modifier les arêtes en conservant la linéarité (mais ne se prononce pas concernant les alternatives) ; faire hériter MutableLinearPreference de MutableLinearEdges.

  • Ajouter MutableLinearPreferenceFixedAlternatives, qui hérite de MutableLinearEdges et garantit l’immuabilité des alternatives

  • Permettre de récupérer un NavigableSet d’alternatives depuis une ImmutableLinearPreference, et réfléchir à l’extension à la version muable

  • Modifier la proposition d’interfaces de profils en ajoutant la simplification que l’ensemble d’alternatives ne bouge jamais, même dans le cas d’un profil muable : les préférences peuvent se compléter ou se modifier, mais dans cet ensemble fixé. Donc un profil a un ensemble d’électeurs ET d’alternatives fixe. Un profil ne peut pas être vide, donc doit contenir au moins un électeur et au moins une alternative. En outre, la notion de Complete profile semble mal définie actuellement : un profil complet devrait être un profil contenant uniquement des préférences complètes. ImmutableCompleteProfile devrait s’appeler ImmutableProfile (c’est le cas le plus courant). Les alternatives associées au profil sont identiques aux alternatives dans le graphe réflexif des préférences de chaque électeur (grâce aux boucles réflexives, toujours présentes).

  • Améliorer interface SocialWelfareFunction et créer d’autres interfaces : AntiSymmetricSocialWelfareFunction contient une méthode #aggregate qui envoie un AntiSymmetricCompleteProfile vers une CompletePreference; SocialWelfareFunction étend AntiSymmetricSocialWelfareFunction et envoie un CompleteProfile vers une CompletePreference.

Autres idées

  • GUI pour voir les résultats d’application d’une SWF sur un profil.

  • Le GUI permet d’afficher et d’éditer le nombre d’électeurs qui ont les mêmes préférences. Cela permet de travailler également avec de gros profils.

  • Implémenter d’autres règles de votes telles que celles proposées dans Whale4. Elles sont toutes disponibles dans le GUI proposé.

  • Étudier les différents formats JSON renvoyés par Whale, les comparer aux données dans les formats correspondants de PrefLib (qui sont le standard établi), et documenter un ou plusieurs formats JSON dans la documentation, permettant de représenter tout ce que vos formats PrefLib permettent de représenter, et aussi compatible que possible avec le format utilisé par Whale : vous pouvez proposer des améliorations par rapport au format de Whale, mais les différences éventuelles doivent être documentées et justifiées.

  • L’utilisateur peut visualiser un profil créé dans Whale4.

  • L’utilisateur peut visualiser les résultats d’une élection selon d’autres règles (cf. Whale4).

  • L’utilisateur peut accéder à un profil au format xmcda-modular.

  • Séparer la partie GUI dans un projet propre: J-Voting-GUI