Résumé des épisodes précédents:
En théorie des jeux, les fonctions d’évaluation permettent d’évaluer des situations, de les comparer, et donc de faire des choix renseignés l’Independent Chip Model (ICM) est la fonction d’évaluation de référence pour les tournois de poker, et on cherche à trouver mieux, notamment pour un grand nombre de joueurs l’ICM est long à calculer pour un grand nombre de joueurs.
Dans mon précédent billet, je vous parlais des fonctions d’évaluation en théorie des jeux, plus particulièrement dans les tournois de poker No-Limit Hold’Em (NLHE), et spécifiquement de l’Independent Chip Model (ICM).
Pour rappel une fonction d’évaluation donne une estimation probabiliste des gains de chaque joueur en fonction de l’état du jeu.
Comme beaucoup, j’ai eu ma période “poker”. Elle s’est très vite traduite chez moi par la conception d’outils divers d’aide et d’analyse de jeu (parce que je suis trop mauvais), et a donné naissance à cette petite bibliothèque Java. J’ai tiré beaucoup de cette expérience, que ce soit en théorie des jeux, en algorithmique théorique et pratique, en intelligence artificielle ou même en architecture logicielle.
J’avais déjà croisé un exemple d’implémentation de property wrapper et devant leur simplicité, je m’étais mis en tête de créer un property wrapper accélérant le stockage de valeurs dans les UserDefaults.
Il se trouve que dans mes expérimentations autour de Combine j’avais bien envie de créer un wrapper publiant les nouvelles valeurs seulement après les avoirs stockées (voir ici).
Après mon premier petit TP autour de SwiftUI et Combine pour générer mes attestations de déplacement ~à la barbe de la maréchaussée~ à la volée voire en retard, j’ai profité de l’adaptation au second format d’attestation pour faire des explorations un peu plus poussées de mon architecture autour de Combine.