Addition of the QuestionPriceArea class

[av1m]

Profile dependency.
We have created a fake Profile class so that the code can compile

Once PR #44 (Profile) is merged to master, we will merge master with our PR and resolve the conflict by taking the Profile class from master

Despite a slight delay on the Profile side, we still insist on this PR and hope that the PR on adding Profile will be merge because we will need QuestionPriceArea for the last Java iteration.

We assume the rules and we know that this PR will be sanctioned if Profile is not merge in time.

[clemencecousin]

La classe QuestionPriceAreaTests n'est pas dans le bon package profile. Je vois qu'il y a ici 2 packages profile dans le dossier test : .../apartments/profile et .../apartments/valuefunction/profile.
Il faut mettre la classe de test dans celui contenu dans le package de la valuefunction et supprimer le premier package.

[oliviercailloux]

Ajouter le test unitaire suivant. Créer une AVF linéaire (par exemple, celle par défaut pour un étudiant). Poser la question : êtes-vous prêt à payer x € pour y m² en plus ? Supposer que la réponse est positive. Adapter l’AVF. Considérer un appartement a et un appartement b x € plus cher et avec y m² en plus. Vérifier que b est préféré à a avec la nouvelle avf.

Il faut que ceci fonctionne pour toute valeur (ce n’est pas possible de tester pour toute valeur, mais le test peut vérifier pour certaines).

[clemencecousin]

Compte tenu de la dépendance de cette tâche avec le travail de Gabriel et de Morgane, les équipes m'ont demandé s'il serait possible de résoudre le problème de resolve grâce à une issue (qui serait traitée avant la fin de cette itération) et de merge la PR actuelle. Cela permettrait à Morgane et Gabriel de vous soumettre leur travail. Qu'en pensez-vous ?

[oliviercailloux]

Quelle est cette PR dépendante que vous mentionnez ici ? Je ne suis pas enthousiaste à l’idée de fusionner cette PR ci, car la résolution est la partie cruciale de cette PR, et étant incorrecte actuellement, elle risque de mal orienter le projet. Ceci s’applique d’autant plus que l’autre PR utiliserait cette résolution. Si l’autre PR n’utilise pas la résolution, je vous propose de retirer l’aspect résolution pour le moment (lancer UnsupportedOperationException) et fusionner.

[EtienneCartier]

Bonjour Monsieur,
Les changements que vous nous demandez auraient un fort impact sur la conception des weights pour les profiles, mais bien plus encore sur la conception des profiles types. En effet, cela nous demanderait de modifier intégralement la conception et l'implémentation de ces profiles types. Cela nous demanderait aussi de repenser le calcul de la fonction de valeur d'un appartement. De plus, nous ne comprenons pas les éléments ayant changés depuis la dernière itération qui vous avaient amenés à valider l'approche actuelle des poids individuels des critères et qui vous pousse aujourd'hui à rejeter cette approche pour vous tourner vers la pondération de critère les uns par rapport aux autres. Enfin, comme mentionné plus haut, à moins de deux jours de la fin de l'itération, le délai nous semble pour le moins compliqué à tenir étant donné l'ampleur du travail de modélisation puis d'implémentation nécessaire. Pour résoudre pour le moment cette question, ne pourrions nous pas augmenter l'intervalle de poids du critère privilégié par l'utilisateur en multipliant les bornes par le taux "rate" que nous calculons actuellement.
Nous pourrions par la suite ajouter une méthode permettant de gérer plusieurs question pour garantir la cohérence entre les résultats (pour éviter que le rapport entre deux poids soit altéré par une autre question)

[oliviercailloux]

Ne paniquons pas : la seule chose à corriger dans cette PR est la méthode resolve. Je pense que mon e-mail précédent, que vous indiquez avoir compris, donne le calcul à effectuer pour trouver la nouvelle borne de l’intervalle, et c’est tout ce qui me semble nécessaire pour cette méthode.

J’insiste donc pour une implémentation corrigée, et je vous propose de réduire les ambitions. Sinon, on oriente véritablement le projet dans une direction qui n’a pas grand sens.

Concentrez-vous sur l’implémentation d’une question : surface par rapport au prix, par exemple.

Votre logique de profils me semble bonne, et je ne crois pas qu’il faille y changer grand-chose. En particulier, ça ne change pas le calcul de la fonction de valeur. Le profil tel que vous le concevez actuellement me semble correct pour ce qui est de ses champs, pour l’essentiel (sauf que j’aurais commencé par un seul range pour seulement le critère surface, pour simplifier). Il faut seulement interpréter le range différemment. Je ne vois pas de contradiction par rapport à mon discours passé.

[oliviercailloux]

Nous pouvons en discuter via Teams vers 16h, si cela vous convient.

[av1m]

Merci, cela nous convient. Nous serons disponible pour 16h (@oliviercailloux)

[av1m]

La classe LinearAVF a été modifié afin de mettre les fonctions permettant de retourner les value function à public

[oliviercailloux]

FUTURE : test impliquant fonctions de valeurs avant / après résolution d’une question (comme indiqué dans une autre review).

[clemencecousin]

Lors de l'ajout des tests, nous avons découvert un problème : l'adaptation se fait mal lorsque l'on place certaines valeurs dans la question. L'issue #63 a été ouverte à ce sujet.
Le FUTURE mentionné plus haut a été implémenté.