La classe FonctionPension est fragile

[mbaudin47]

• Le code utilise des constantes pour les indices de scénario, :

https://github.com/mbaudin47/retraites/blob/1bec1a174175ac884a9ba7394b5d348812fd8528/retraites/FonctionPension.py#L134

C'est fragile, car les indices pourraient changer dans le futur, ce qui casserait le code, sans nécessairement faire échouer les tests unitaires.

• Le code implémente le calcul de P en fonction de S, A et D:

https://github.com/mbaudin47/retraites/blob/1bec1a174175ac884a9ba7394b5d348812fd8528/retraites/FonctionPension.py#L103

Ce code est une simplification du code utilisé dans le pilotage 5 pilotageParSoldeAgeDepenses:

https://github.com/mbaudin47/retraites/blob/1bec1a174175ac884a9ba7394b5d348812fd8528/retraites/SimulateurRetraites.py#L614

Factoriser serait peut-être possible, sans nécessairement nuire à la performance.

• Utiliser une fonction Symbolique améliorerait peut-être les performances.

[josephmure]

Factoriser serait peut-être possible, sans nécessairement nuire à la performance.

* Utiliser une fonction Symbolique améliorerait peut-être les performances.

Parles-tu de la même chose dans ces deux suggestions ? Ne sont-elles pas contradictoires ? Ou veux-tu remplacer pilotageParSoldeAgeDepenses par une SymbolicFunction ?

[mbaudin47]

Oui, tu as raison : c'est contradictoire ! En effet, si la classe FonctionPension définit une SymbolicFunction et qu'on factorise, alors on doit développer aussi les autres pilotages sous la forme d'une SymbolicFunction. Ce n'est pas forcément souhaitable, car OT deviendrait alors une dépendance profonde du composant retraites : ce n'est pas nécessairement une bonne idée.