Archon - Optimal Seating

[Mimmy]

OK je lance ça ce soir...

[Ankha]

Mise à jour des contributeurs:
Ankha: 1 - 140 000 OK
2wayspeaker: 140 000 - 140 500 OK
Selim: 140 500 - 140 750 OK
Ankha: 140 750 - 141 500 OK
Lestat: 141 500 - 141 900 OK
Ankha (132): 141900 - 142 499 OK
Ankha (132): 142 500 - 142 999 OK
Ankha (132): 143 000 - 143 999 OK
Ankha (azure81/build8): 144 000 - 144 999 OK
Ankha (132): 145 000 - 150 000 OK
Ankha (build8): 150 001 - 159 999 OK
LSJ: 160 000 - 174 999
Ankha (8): 175 000 - 175 999 OK
2wayspeaker: 176 000 - 176 499 OK
Ankha (132): 176500 - 176 999 OK
Ankha: 177000 - 177 999 OK
Mimmy: 178000 - 179 999
Lestat: 180 000 - 190 000 OK
Lestat: 190 000 - 200 000 OK
Ankha (build8): 200 000 - 210 000 OK
Mimmy: 210 000 - 220 000 OK
Apolokia final: 220 000 - 228 550 OK

[Lestat]

Tu as des news de LSJ ou bien tu veux qu'on s'y colle ?

[Ankha]

Tu as des news de LSJ ou bien tu veux qu'on s'y colle ?

C'est en cours chez lui.

[zkopiosy]

J'arrive 10 ans apres la guerre, mais pour ce genre de problèmes, une des meilleures approches, surtout pour les seating qui vont demander encore plus de calcul, c'est de faire un algo probabiliste.

En gros, tu tires au hasard des combinaisons, que tu note en fonction de si elle réponde plus ou moins aux critères idéaux. Tu balance ça, une nuit de temps en temps, logiqement tu devrais rapidement trouver des solutions qui sont bien meilleures que celles que l'on a actuellement même si elles sont pas parfaites. Et t'auras pas besoin des ordis de la nasa

Le plus difficile est de fixer le critère de notations:
Pour les points obligatoires si ça déroge c'est direct note à 0 et tu jette la combinaison. Pour les règles qui sont préférables, il faut ajuster un coefficient qui représente à quel point c'est préférable de respecter la règle.

tu gardes tes 5 meilleures combinaisons tirées par placements, tu regardes si leur classement réponds à tes espérances, si c'est pas le cas tu ajuste tes critères de notations et tu relances.
Ca ira bien plus vite pour améliorer les choses. Bien évidemment tu n'auras pas le meilleur résultat à chaque seating, à moins de faire toutes les combinaisons, mais je crois pas que ce soit le but.

Bon après je sais que l'archon fait les seating par groupe de 25, mais du coup on pourrait améliorer ça aussi
Alors qu'avec un calcul pur, on montera pas au dessus de 25, vu comme vous en chier pour 20....

Tu crois que c'est facilement adaptable?

[Ankha]

J'arrive 10 ans apres la guerre, mais pour ce genre de problèmes, une des meilleures approches, surtout pour les seating qui vont demander encore plus de calcul, c'est de faire un algo probabiliste.

En gros, tu tires au hasard des combinaisons, que tu note en fonction de si elle réponde plus ou moins aux critères idéaux. Tu balance ça, une nuit de temps en temps, logiqement tu devrais rapidement trouver des solutions qui sont bien meilleures que celles que l'on a actuellement même si elles sont pas parfaites. Et t'auras pas besoin des ordis de la nasa

J'ai des doutes sur l'obtention de résultats pertinents vu le nombre de combinaisons.
Sinon, le système de notation est assez simple. Il faut que le placement respecte les règles, puis on mesure le nombre de rencontres doubles, puis la deviation absolue de transferts et de vp.

[zkopiosy]

J'ai fait un truc vite fait, mais apparemment le nombre de combinaison ou 1 des joueur a la même proie dans le tournoi est énorme. J'essaierai de trouver une astuce pour éliminer ces tirages là, si c'est pas trop coûteux.

Je vous tiens au courant

[Lestat]

Sinon Ankha peut peut être mettre ses fichiers sources en ligne qu'on voit le code et ce qui peut être améliorer ?

[Ankha]

Sinon Ankha peut peut être mettre ses fichiers sources en ligne qu'on voit le code et ce qui peut être améliorer ?

Voici les sources en C# :
https://github.com/GiottoVerducci/ArchonSeatings_public

Le programme principal est SeatingsGenerator. Il y a pas mal de code mort que je n'ai pas retiré.
Pour le faire fonctionner, il faut utiliser les directives de compilations USE_PARALLEL et éventuellement SEVENTTEEN, EIGHTTEEN etc. qui permettent de précalculer certaines valeurs en dur.
Les classes utilisées sont SeatingsFactoryBase et Seatings3RFactory.
Seatings3RFactory utilise une machine à état (via le mot clé yield), ce qui permet lors d'une itération de générer un résultat. Sans itérateur, tous les résultats seraient stockés en mémoire ce qui n'est pas possible (trop de résultats).
La machine à état part d'un sous-ensemble de résultats évalués afin de pouvoir les diviser et itérer dessus en parallèle.

Je ne pense pas qu'il y ait d'optimisation purement technique à apporter. J'ai une idée de nouvel algo qui devrait encore diviser les temps, mais je n'ai pas eu le temps de l'écrire.

La grosse optimisation sera de toute manière de générer le minimum (idéalement aucune) de combinaison d'un même seating.

Le programme Reunite permet de regrouper les résultats éclatés dans plusieurs fichiers en un seul en gardant les meilleurs résultats.
Enfin, le programme RuleChecker donne les informations de validité d'un seating donné.

[Mimmy]

Resultats envoyés pour la tranche 178000 - 179999.

Par contre je suis surpris qu'il n'ai généré qu'un seul fichier (pas tres gros) alors que les calculs précédent en avait généré beaucoup.

Est ce normal ou le calcul de la tranche n'est pas bon ?

[Ankha]

Resultats envoyés pour la tranche 178000 - 179999.

Par contre je suis surpris qu'il n'ai généré qu'un seul fichier (pas tres gros) alors que les calculs précédent en avait généré beaucoup.

Est ce normal ou le calcul de la tranche n'est pas bon ?

C'est normal, merci à tous, j'ai ce qu'il me faut.