[critor]

A tous nos membres,
partenaires,
contacts,
amis,
et même lecteurs anonymes,

Et au nom de toute l'équipe,

Joyeux Noël 2020 !



Que la magie de Noël vous fasse oublier, au moins pour un temps, la morosité ambiante.

[Lephe]

Bonjour à tous les membres ! Avec notre concours de rentrée tout juste terminé, voyons comment vous avez résolu notre deuxième défi, le défi Python de Quetzalcoatl !

La participation à cette épreuve aura été similaire à la première, avec 141 participations soumises par 20 personnes. 11 d'entre vous se sont déclarés de la team TI, et 4 de la team Casio (les autres n'ont rien indiqué). Merci beaucoup pour toute la science que, comme on va le voir tout de suite, vous avez déployé pour optimiser ce défi ! o/

Cette épreuve consistait à traverser une caverne à l'aide de l'excavatrice transformée en ballon. Comme l'épreuve précédente, l'objectif était de minimiser la quantité d'énergie dépensée, dont j'ai détaillé le calcul dans un topic quand on a réalisé que c'était moins évident que prévu.

Le contrôle du ballon se faisait en spécifiant des triplets :
• L'accélération verticale du ballon, ay.
• La vitesse de changement de forme, da.
• La durée de validité du contrôle.

Les coûts étaient répartis sensiblement ainsi :
• 10 points par contrôle effectué.
• Un léger coût sur les changements de forme, croissant avec |da|.
• 7 points par collision, sachant que si on s'enfonce dans la roche le nombre de collisions à chaque instant peut être très élevé.

Voyons voir ce que vous avez pu trouver ! L'analyse ci-dessous est purement la mienne, j'aurai sans doute raté des détails croustillants, donc n'hésitez pas à préciser dans les commentaires.

Le classement

17. Golden Man () : 6058.5 (Programme : q5.py)

Comme dans l'article précédent, la première participation ici est aussi une des plus malines. Avec un seul ordre d'une seule unité de temps, Golden Man fixe la vitesse verticale à -0.27 et descend en ligne droite jusqu'à la ligne d'arrivée. Le script auto-complète la séquence d'instructions en ne faisant rien jusqu'à la fin.

Soumettre des ordres coûte cher, donc cette idée est logique. Mais les collisions coûtent infiniment plus cher, et à plusieurs moments le ballon est entièrement dans la roche. Or, l'algorithme codé par Critor évalue en gros la surface de l'intersection de l'ellipse du ballon avec la roche, et pénalise d'un multiple élevé de cette surface, donc le score explose.

16. Ptitjoz () : 2165.3 (Programme : q124.py)

Ptitjoz est le premier à faire des paraboles. Comme vous l'avez sans doute remarqué, la première composante de chaque ordre est l'accélération verticale du ballon. Sur la période indiquée par chaque ordre, le ballon fait donc une parabole montante ou descendante.

Le passage de la première section est très propre avec absolument aucune collision. Et il y a une technique intéressante au niveau de la section infranchissable, où le ballon plonge dans la roche pour se mettre dans une position favorable à la remontée. C'est une mécanique intéressante qu'on aurait pu vous inciter à exploiter. Mais le jeu était équilibré de façon à punir inconditionnellement les collisions, donc ça n'est pas arrivé : il n'était jamais intéressant de faire des concessions.

15. Nagero () : 1980.5 (Programme : q131.py)

Comme le programme d'exemple, la participation de Nagero ne s'écarte pas trop des accélérations verticales ±1. Ça a l'avantage d'éliminer des paramètres dans la recherche d'un chemin, mais ça oblige à faire beaucoup de vagues et donc passer beaucoup de points sur les ordres.

La trajectoire évite quand même la plupart des passages difficiles et pourrait presque attraper le dernier lot à quelques instructions près sur la fin !

14. Arm234 () : 1132.5 (Programme : q104.py)

Comme si ce n'était pas assez de le faire une fois, Pavel a là aussi écrit une version pour ordinateur du programme de l'épreuve, et Arm234 est le premier de ce classement à s'en être servi.

Quelque chose qui devient assez vite évident lorsqu'on cherche de façon interactive, c'est que malgré l'insistance du sujet à vous faire utiliser des paraboles, il est parfaitement possible d'avancer en ligne droite en spécifiant une accélération verticale nulle pendant une période donnée.

À partir de là, le jeu devient surtout d'identifier les segments qu'on peut parcourir et d'utiliser une série d'instructions économe en score pour fixer la vitesse verticale et la forme du ballon, puis ne rien faire pendant toute la durée de chaque segment, ce qui ne coûte aucun point au score !

On retrouve de nouveau la parabole directe au niveau du passage infranchissable, puisque quitte à passer en force autant ne pas consommer en plus des appels à modifier_vol().

J’ai choisi de ne rien faire avec la calculatrice (j’ai une NumWorks), car je trouvais cela assez compliqué pour pouvoir réaliser les différents textes, j’ai donc avancé à tâtons avec l’émulateur pour pc avec TKinter en me sevrant des captures d’écran des premiers qui m’ont beaucoup servi pour savoir où aller et quels tracés réaliser.

(message original)

13. CaptainLuigi () : 825.5 (Programme : q119.py)

CaptainLuigi a lui aussi utilisé le programme de Pavel. En fait ça se voit assez vite au formatage du code puisque l'outil génère une version compacte avec une boucle for. Sauf fourberie particulière, les personnes qui n'ont utilisé que leur calculatrice ont gardé la séquence de modifier_vol() donnée en exemple. Donc qui utilise quoi se devine assez bien au premier coup d'oeil.

Cette participation est la toute dernière à ne pas avoir aggressivement abusé de lignes droites partout, et doit son placement au passage rigoureux de tous les points serrés, qui totalise un nombre faible de collisions (n'oubliez pas que la surface de l'intersection compte, ici on frôle à peine).

J'ai tenté 2/3 fois sur Casio, vers 1000 environ .
Mais à force d'attendre l'importation des modules qui prenait 20,30 secondes, j'ai jeté un coup d'œil à l'outil que Pavel avait développé , et très rapidement j'ai fait ce score un peu plus décent de 825.5
(j'avais une participation bien en dessous mais invalide )

(message original)

12. Tituya () : 537.5 (Programme : q15.py)

Pour quelqu'un qui dit ne pas avoir cherché beaucoup, Tituya a cherché droit au but : c'est fait à la main, on a les lignes droites, un passage impeccable de toutes les sections, et le ballon ne change même pas de forme ! Un total de 21 instructions directes et efficaces.

À partir de là, le chemin ne change plus fondamentalement et on va surtout voir moins de collisions sur la section infranchissable et moins d'instuctions.

Voilà ma méthode : J'ai simplement essayé de faire les trajets le plus cours possible. Sachant que les trajets les plus cours sont ceux allant droit, j'ai construit mon programme en jouant sur ça et en essayant d'éviter au maximum les murs.
Rien de plus, rien de moins. J'ai moins été intéressé par ce concours, je n'ai pas plus cherché que ça.

(message original)

11. Wistaro () : 499 (Programme : q64.py)

Le programme soumis par Wistaro a la propriété unique de soumettre une instruction par unité de temps. Toutes les (0,0,1) ne coûtent aucun point, mais il en reste 24 autres. Et pourtant, son score est en-dessous de 500 points !

Le secret ? Un ajustement aléatoire habile (quoique manuel) des instructions. Quasiment tout le monde a travaillé manuellement sur ce défi, et ce n'est pas surprenant étant donné la complexité du calcul des collisions et l'absence d'un cadre formel facile dans lequel attaquer le problème.

Je ne vous cache pas qu'après le premier défi je ne m'attendais pas du tout à ce qu'on recoive une participation de ce style !

Ma méthode pour ce concours n'est pas vraiment surprenante. J'ai tout d'abord commencé par lancer le programme sur ma calculatrice (TI-Nspire CX CAS munie de Khi-CAS + micropython). j'ai tâtonné à la main pour essayer de comprendre le rôle de tous les paramètres.
J'ai aussi essayé de décortiquer le code source en Python, mais ça n'a pas servi à grand chose vu mon faible niveau dans ce langage
Une fois cela bien compris, j'ai utilisé le programme pc de Pavel pour essayer de trouver la trajectoire la plus optimisée. Je le remercie beaucoup d'ailleurs, ça m'a bien aidé, même si je trouve que ça nous facilitait la tâche

Après plusieurs essais infructueux, j'ai fini par atteindre 499 en jouant sur les différents paramètres de manière aléatoire. J'ai réussi une fois à faire 480, mais malheureusement je n'ai pas pensé à sauvegardé la trajectoire

(message original)

10. commandblockguy () : 462.5 (Programme : q26.py)

La participation de CommandBlockGuy pousse tellement le concept de ligne droite à bout que son programme est structurellement une alternance entre des paraboles pour changer de direction et des lignes droites pour progresser dans la caverne (sauf au passage du premier pincement où il enchaîne deux paraboles).

Vous pouvez voir que le chemin emprunté est le même pour toutes les soumissions restantes, mais le score continue de descendre drastiquement. Il y a plusieurs raisons pour ça, mais une en particulier était volontaire. À l'origine, Critor avait proposé que la première composante de chaque instruction soit la vitesse verticale (ce qui est somme toute plus logique physiquement parlant). Voyant les retours sur le premier défi, j'ai suggéré d'utiliser l'accélération à la place.

Spécifier une accélération constante par morceaux fait bien sûr des paraboles au lieu de lignes, mais ce n'est pas tout. Ça ajoute au problème une variable cachée qui est la vitesse verticale. En particulier, on ne peut pas juste déplacer des instructions d'un endroit à un autre de plan de vol, parce que si la vitesse verticale est différente au points de départ et d'arrivée, leur effet diffère aussi.

Derrière tout ça il y avait aussi l'idée que des changements sur le début du plan de vol se répercutent assez violemment sur la fin et nécessitent de réajuster la fin. J'espérais que les candidats qui partent sur un début différent les uns des autres restent « coincés » dans ces espaces de solutions, évitant ainsi qu'il n'y ait qu'une seule solution comme au premier défi.

This time, I basically just did everything manually, trying to minimize my number of collisions. I would have tried to automatically test solutions again, but I was much busier for this round than the last one. I ended up with a best score of 455.5, but because that was already taken I slightly changed it to get a score of 462.5.

(message original)

9. Filoji () : 454.5 (Programme : q13.py)

Un autre aspect qu'on a voulu essayer, et qui dans le cas de Filoji a joué en notre défaveur, était de publier les images des trajets empruntés par tout le monde. Comme la variable cachée (la vitesse) n'est pas visible sur les images, contrairement au premier défi ça ne donne pas toute l'information sur la solution.

On a pensé que ça aiderait tout le monde à trouver des astuces (par exemple le fait qu'on pouvait faire des lignes droites) et motiverait un peu ceux qui avaient du mal. Qu'en avez-vous pensé ? Est-ce que ça vous a aidé, ennuyé ? Et par extension, même question sur les infos publiques du troisième défi (où il y a infiniment plus d'informations cachées).

C'est pas compliqué dans la vie, il faut tricher !
Donc, pour commencer, j'ai vu que le concours commençais, mais c'était le même type de challenge que le précédent...
Je me suis dit "Après tout, tente !", et c'est ce que j'ai fait.
Je ne vais pas vous mentir, j'ai préféré le 1er, car je le trouvais plus simple à comprendre. En plus, je n'ai pas vraiment d'histoire sur celui-ci, j'ai très vite réussis à trouver une solution qui m'avais placé en ~5ème, et je me suis arrêté là. Comment j'ai réussis à faire ça ? Ben j'ai juste regarder les participations ennemis. Je trouvais ça bien à la base de voir l'avancement des autres, mais quand le seul but pour moi était de recopier le chemin des autres, je me suis très vite lassé.

(message original)

8. Ti64CLi++ () : 406.8 (Programme : q138.py)

Parfois on se demande ce qu'on ferait sans Pavel.

Alors pour cette fois, j'ai tout fait avec l'utilitaire de Pavel (au passage, merci pour tout ), j'ai tenté une première fois, où j'ai obtenu un score d'environ 600 il me semble, puis un deuxième jet m'a permis d'atteindre les 490.
Enfin, j'ai fais joujou avec les paramètres, sans trop jamais vraiment me pencher dessus, ce qui m'a permis d'avoir ce score de 406,8.

(message original)

7. Jeffitus () : 234 (Programme : q136.py)

Le saut entre TI64CLi++ et Jeffitus est flagrant : presque 200 points. Il y a bien sûr quelques instructions en moins, mais ce que fait vraiment la différence c'est la quantité de collisions au niveau du passage infranchissable.

Quand Critor a suggéré ce sujet j'ai tout de suite pensé que je pouvais générer les deux courbes définissant le plafond et le sol en tirant aléatoirement les coefficients d'une décomposition de Fourier pour deux fonctions. Mais ça posait un problème qui est que les courbes pouvaient facilement se croiser. Dans l'exemple ci-dessous, l'amplitude permet aux courbes de traverser tout l'écran, et les composantes majeures du profil spectral sont partagées pour éviter les intersections. Mais on peut toujours s'en sortir avec deux (voire une seule) lignes droites.

Du coup j'ai changé de méthode et j'ai généré la position du plafond et la hauteur de l'espace naviguable à partir des profils spectraux. De cette façon, il était facile de garantir que le résultat serait toujours positif, et on a beaucoup plus facilement des passages serrés.

En fin de compte, Critor a choisi une instance avec un passage infranchissable, ce qui vous obligeait à faire des compromis. On a vu au début de ce classement qu'éviter à tout prix les collisions joue le rôle le plus important dans les bons scores, et ça se voit encore même dans le top 10.

The first score I submitted was done by hand, using a script written by commandblockguy for the PC. I'll note that initially I didn't really touch the second parameter, since I didn't really understand what it was doing at first. I saw that some people were talking about Pavel's GUI version, so I decided to try that out and sure enough I began getting better scores. It was also around that time that Afyu mentioned the second parameter, and I started looking into how it worked. With that knowledge I was able to get below 400 easily, and below 300 soon after that. I think I probably could have improved my score more, but since I really only started trying to improve just a few days before the contest ended I'm pretty happy with how my score turned out.

(message original)

6. Ne0tuX () : 217 (Programme : q111.py)

Ne0tux a lui aussi faire la plupart de la recherche à la main. Au fond, le défaut sans doute de ce défi, c'est qu'il y a un aspect de grind assez conséquent. C'était aussi le cas dans le passé (par exemple pour le problème de sélection d'équipe Pokémon en 2019) mais dans ces cas-là on pouvait aussi approcher la solution à l'ordinateur.

Je ne suis pas surpris qu'il y ait eu très peu de scripts pour ce défi, et à autres paramètres égaux je trouve ça dommage (ceci n'engage que mon opinion). Le troisième défi tranche beaucoup en vous tous faisant programmer une solution, et selon si vous avez aimé ça pourra influencer le format des prochaines éditions. N'hésitez pas à dire en deux ou trois mots ce que vous avez préféré, ça nous informe beaucoup.

J'ai de nouveau tiré profit d'Omega en ligne pour valider ma participation, mais je dois remercier Pavel car c'est avec sa GUI que j'ai testé mes idées. C'est la première fois que je ne produis aucun algorithme d'optimisation ; je me suis contenté d'appliquer au mieux la stratégie déduite du code et des participations visibles. Le fait de voir ce qu'ont fait les autres était une nouveauté. D'un côté, j'ai trouvé intéressant de constater (au début tout du moins) que des scores proches avaient parfois des visuels différents. D'un autre côté, accéder à ces visuels était une solution à moindre effort comparé à tout expérimenter soi-même. Ma double nature humain/développeur m'a fait choisir la facilité en m'intéressant aux 2-3 premiers visuels du classement et c'est ainsi que j'ai validé quelques d'intuitions obtenues par le code : possibilité de faire des lignes droites à moindre coût, besoin d'un minimum de collision pour un score minimum.

(message original)

5. LeGmask () : 213.6 (Programme : q108.py)

Comme la dernière fois, je vous laisse avec les explications brutes du top 5, qui sont déjà on ne peut plus complètes par elles-mêmes.

Vous noterez quand même, si vous lisez le code, que les débuts sont extrêmement proches. L'usage de lignes droites réduit drastiquement le nombre de possibilités de chemin. Mon espoir qu'il y ait ultimement plus d'une solution vraiment compétitive n'était donc qu'à moitié fondé, car seule les instructions de fin diffèrent vraiment d'une soumission à l'autre.

Sérieusement, en vrai pour tout vous dire ce concours était d’autant plus simple que le premier niveau compréhension, peut-être un peut trop, et trop répétitifs par rapport au dernier concours, mais je ne m’en pleins pas on a déjà l’immense chance d’avoir de superbe concours rien que pour nous 😊

Ce qu’il en est de ma solution : bien bah tout d’abord je me suis empréssée de faire une adaptation de labgui le script de Pavel pour le premier concours (https://gist.github.com/LeGmask/88eaf69 ... eb16d79dbd ) je m’apprêtait a voir avec cent20 pour faire profiter la team numworks de cette avantage ou tout le monde, sauf que Pavel ma devancé. J’avais fini mon script le matin 9h quelques heures après, Pavel qui nous sort ca version :notlikethis: . Néanmoins j’ai essayé les deux et je trouvais ma version adaptée de labgui bien plus efficace que la nouvelle fournis par Pavel. J’ai alors cherché un peut avec mon nouvel outil et fait un score aux alentours de 590 de mémoire.

Après cela j’ai laissé passez beaucoup de temps, semaine de DS + préparation à mon championnat de voile à Dunkerque… première semaine des vacances j’ai réussi le mercredi (étant en « formation » avant) à regarder un peut, et j’ai réussi à descendre juste en dessous de Afyu, l’idée que j’avais vu est que si ont réduisait le serpentin avec le 2e paramètre, il fallait faire ajouter l’inverse pour annuler le fait qu’avancer consomme du score… Le weekend de cette première semaine de vacance j’ai donc pus trouver mieux que le score actuel de Pavel qui avait 218, je me place donc premier avec 216.5.

Arrivée à Dunkerque, Pavel reprend sa place avec 211, puis Afyu passe devant aussi, de plus qui dit championnat de France ne dit pas beaucoup de temps libre, la journée sur l’eau le soir dodo. J’ai néanmoins trouvé un peu de temps et réussi à me placer devant Afyu, a ce moment la j’ai donc décidé de faire un algorithme pour optimiser le tout, cette algorithme ajoutait simplement aléatoirement de petites valeurs au différentes variable, et finissait par toujours retomber sur 211, avec plus de temps j’aurais peut-être pus trouver mieux mais je ne pense pas que c’était faisable.

J’ai finalement été dépasser par Tiny_Hacker, et cent20 mais je n’avais pas vraiment le temps de faire une amélioration, puis bon j’ai déjà un lots avec une calculatrice je n’avais pas non plus la motivation de faire beaucoup mieux 😊.

Encore une fois grand merci pour ce concours, et je repose mon idée, d’une évaluation automatique pour le concours afin d’éviter a critor de tout faire à la main. J’ai ici décider d’aider ceux qui en avait vraiment besoin afin de rétablir l’équilibre par rapport au premier défi ou je me suis fait aider.

(message original)

4. cent20 () : 213.502 (Programme : q127.py)

Ma méthode en quelques mots

Un algorithme dynamique, arborescent, basé sur des séries génétiques, analysé par une IA dédié à cet usage dont je ne peux pas révéler à cet instant, tous les secrets.

Comment tout ceci fonctionne ? Il est temps de révéler tous mes secrets.
C'est assez simple. Commençons par définir ce qu'est un algorithme

Un algorithme est une suite finie et non ambiguë d’opérations ou d'instructions permettant de résoudre une classe de problèmes

J'ai donc mis au point un algorithme, il était arborescent car le défi l'était, l'optimisation d'un trajet dépendait du précédent. Le caractère génétique vient du fait qu'une fois que j'ai obtenu une bonne série, mon IA l'étudie à nouveau pour l'optimiser si cela est possible. Comme je l'ai promis dans le forum, il est temps de vous révéler les secrets de cet algorithme.

Code: Select all

# Attendre que le grand Pavel propose un outil de recherche sur PC

Boucle de recherche : Quand vous arrivez à la dernière étape, il suffit de boucler sur la première

Code: Select all

'''
Proposer une solution
L'optimiser
Regarder les réponses des autres utilisateurs
Mettre une baffe à l'IA pour qu'elle s'adapte
Proposer une meilleur solution, inspiré des autres propositions.
Analyser mon score à mi chemin et comprendre que s'il est supérieur au score de la meilleur proposition # # c'est que rien ne va.
Mettre à nouveau une baffe à l'IA pour qu'elle s'adapte
Troller sur le forum en racontant n'importe quoi, l'essentiel est de faire croire que votre score est imbattable.
Prendre beaucoup de plaisir, et c'est le plus important, à chaque palier franchis dans la progression, ils ont été exposé clairement par Pavel et Afyu donc inutile de les réexpliquer.
'''

Quelques regrets
- Avoir trop chauffé Afyu, qui m'a grillé brillamment pour le coup.
- Avoir cru, trop tôt, que Pavel avait trouvé le meilleur score, j'aurais pu obtenir le 211 mais mon algo de recherche ne pouvait pas y arriver à cause de son fonctionnement : "Regarder les réponses des autres utilisateurs"

J'ai adoré ce deuxième défi, trouver les différentes astuces lors de la recherche est vraiment jouissif.
J'ai vaguement codé une optimisation itérative sur des intervalles prédéterminé pour gratter la 3ème place, mais n'ayant pas mis assez de décimales un joueur à pu s'intercaler entre mon résultat et celui de Afyu.

(message original)

3. TIny_Hacker () : 213.501 (Programme : q139.py)

Thank you for this awesome contest!
When I first entered, I was not really attempting to get a good score but figured that since there were hardly any entries I might as well see what I could come up with since even a huge score would get me into the top 13. I discovered Pavel's GUI searching for information on Planet-Casio, and I messed around trying to get a path that got as few collisions as possible. I ended up with a huge score, which I never bothered to submit.

After messing around some more, I realized I could move in straighter segments by making a small segment before the current and aiming it in the direction I wanted to go. After making a path like this, I ended up with a score of 1,029.5 which I deemed good enough to submit. After more people started sending their solutions and getting better scores, I decided to look back into my current path again. After removing quite a few collisions, I got a score of 647.5, which roughly followed the path that the people ahead of me used. I have to admit, this contest was quite addicting for me!

After a few more days, I had managed to reduce my score to 449.5, and I couldn't seem to figure out how to get it any lower. I realized that there must be a key thing I was missing, seeing the 200 point difference between my score and the scores below me. The next day, Afyu gave me a hint which helped quite a bit, and I discovered the trick to getting into the 200s! The next day, I made a modified version of the GUI which displayed my score for every step along the path, so that I could make sure I was always improving rather than getting the same or a worse score. After a few hours of trying paths, I managed to get my score to 216.5, which I "broke" in order to make it fit into the ranking since 216.5 had already been taken by Pavel. I finally was able to reduce my score to 214, which I submitted and gave up on reducing afterward. However, around 45 minutes before the deadline, I realized that my chances of getting a TI-Nspire were much less than I thought because I had forgotten that there was only one NumWorks in the prizes this time!

However, Afyu told me that one of my segments was too short, and when I compared my path to the ones in front of me that was true! I discovered that the reason I had missed that earlier was that the decrease in the score is not immediate, and so it did not appear to be a better path because I was comparing it in my tweaked version of Pavel's GUI. After I reached 213, I changed some more code in Pavel's GUI to allow me to change the middle argument more precisely, and I was able to sneak my score into 3rd!

(message original)

2. Afyu () : 213.5 (Programme : q110.py)

J'ai découvert l'énoncé avec 4 jours de retard et j'ai commencé mes recherches sur la ressource NumWorks avec le Workshop officiel.
J'ai placé des commandes modifier_vol(n1, n2, n3) en tatonant, jusqu'à avoir une solution convenable.
J'ai alors 22 étapes et une consommation à 3567.5.
Par exemple, la longue ligne droite entre le premier et le deuxième stalactite est coupée en 4 segments mis bout à bout... inutilement.

Puis, j’ai fait un deuxième essai à 2034.5 et ensuite un troisième à 1964.5 et un à 1666 avant d'arriver à mon essai à 1054.5 que j’ai décidé d'envoyer.

Après plusieurs essais et 9 scores plus tard, j'arrive à 541.5 et je décide de passer (enfin !) par un algorithme pour optimiser tout ça.

J'ai repris la ressource proposée pour la NumWorks (version Workshop officiel) et j'en ai supprimé la partie graphique (faute de savoir comment l'adapter sur ordi, en utilisant tkinter plutôt que kandindky pour le module graphique) et j'ai ajouté quelques lignes pour créer 3 listes d'initialisation coord1init, coord2init et coord3init qui contiennent respectivement : les valeurs utilisées comme 1er paramètre, celles utilisées comme 2ème paramètre et celles utilisées comme 3ème paramètre. Et maintenant, avec un peu de recul, je me demande s'il n'aurait pas été plus pertinent de créer des triplets de nombres (un triplet pour chaque commande modifier_vol(n1, n2, n3) plutôt que 3 listes. En fait NON, car sauvegarder puis récupérer régulièrement plein de triplets c'est plus compliqué que de sauvegarder 3 listes.
Dans le script j'ai également créé une variable scoremax qui contiendra mon meilleur score. J'ai également créé 3 listes coord1, coord2 et coord3 qui sont les listes de paramètres sur lesquelles je vais travailler (et qui sont en lien avec les 3 listes d'initialisation). Je modifie aléatoirement une valeur d'une ou de plusieurs de ces 3 listes et je calcule la consommation obtenue. Concrètement, je tire un nombre aléatoire compris entre 0 et la longueur de coord1 - 1. Je stocke ce nombre dans la variable rang1. Ensuite, je modifie coord1[rang1] en lui ajoutant ou en lui retirant une certaine valeur ou en ne la modifiant pas, avec l'instruction coord1[rang1]+=0.01*(randint(0,2)-1) qui ajoute ou retire 0.01 ou ne fait rien. Je fais de même avec coord2 et coord3. Ensuite, je compare la consommation obtenue, donc state[4], avec mon scoremax. Si le score obtenu est meilleur (donc plus petit), alors je copie les 3 listes coord1, coord2 et coord3 dans mes listes d'initialisation/sauvegarde coord1init et ses consœurs et je stocke mon nouveau meilleur score dans scoremax. Ensuite, au tour de boucle suivant, je modifie de nouveau une valeur dans une ou plusieurs des 3 listes et je compare le score obtenu avec mon meilleur score et ainsi de suite. Tous les 3 tours de boucle, donc tous les 3 changements (qui sont successifs), je récupère la valeur de coord1init et ses deux voisines pour les copier dans coord1, coord2 et coord3. C'est une sorte de réinitialisation de mes 3 listes de travail aux paramètres du dernier meilleur score obtenu.
J'ai parfois adapté ce nombre de boucles à parcourir avant cette réinitialisation, suivant si je voulais permettre un grand nombre de changements ou au contraire rester proche de mon actuelle meilleure solution (finalement 3 boucles était un bon choix).
J'ai également adapté la précision des valeurs que je souhaitais pour les 3 paramètres. Le dernier paramètre semble être toujours un entier (mettre une valeur non entière donne le même le score que mettre uniquement la partie entière).

Avec la publication du classement et des solutions de chacune et chacun des gagnants du premier défi, j'ai vu qu'il pouvait y avoir une histoire de nombre de décimales. J'ai donc tenté de réduire le nombre de décimales de mes paramètres (par exemple, je remplace un 2.42 par 2.4 dans la liste coord1init et je relance mon algorithme jusqu'à obtenir de nouveau mon meilleur score, les autres valeurs ayant alors été légèrement modifiées pour compenser l'écart entre 2.42 et 2.4, et je recopie alors ces autres valeurs qui ont été renvoyées avec mon 2.4 ; si avec 2.4 ça ne me renvoie pas une nouvelle solution avec mon meilleur score, alors je teste avec 2.41, en étant moins exigeant, puis ensuite avec 2.4).

Mon premier score obtenu avec mon algorithme était 537.5 (le 11/10). Je passe sous la barre des 500 le même jour, puis sous la barre des 400 le 16/10 et enfin sous la barre des 300 le 17/10 et je suis finalement arrivé à 265.325 le 21/10. Ensuite, rien. Le néant. Plus aucune amélioration pendant 2 jours. LeGmask, que je remercie grandement ici pour son aide, m'a entendu me plaindre de cette stagnation de mon score sur le chat et m'a donné quelques conseils, en particulier celui d'utiliser l'interface graphique proposée par Pavel - que je remercie grandement ici pour son script généreusement partagé dans les commentaires (page 3). LeGmask m'a proposé une version améliorée par ses soins, qui m'a aidé à comprendre l'importance et l'influence des 3 paramètres et de la variable state[2]. Avant d'utiliser cette interface graphique, j'avais compris qu'on pouvait tracer un segment (droit) avec un triplet de la forme (0, 0, n) avec n un entier. J'avais également compris que le dernier paramètre influait sur la longueur du morceau de courbe placé et que le premier paramètre modifiait l'inclinaison ou la hauteur d'arrivée. Le 2ème paramètre restait assez flou pour moi et j'ai laissé mon algorithme choisir la valeur la plus adaptée pour obtenir un bon score. En suivant les conseils de LeGmask et avec l'interface graphique de Pavel, j'ai compris que le 2ème paramètre modifiait la valeur de state[2] et que la consommation de chaque morceau de courbe placé était bien moindre lorsque state[2] avait pour valeur 0.5 (ce qu'on peut retrouver en lisant le code du script donné pour le défi, à l'endroit du calcul du score, donc de state[4], et ça concerne en particulier la variable dapi qui sanctionne tout écart de state[2] avec la valeur 0.5). Une solution simple serait de modifier le 2ème paramètre de la 1ère commande modifier_vol(n1, n2, n3) afin de mettre la variable state[2] à 0.5 et de ne plus modifier cette valeur. Le problème est que state[2] joue sur l'épaisseur du tracé et qu'il est nécessaire de modifier cette valeur pour réduire l'épaisseur du trait pour passer certains passages étroits de la cave sans toucher les bords (en fait : le passage sous chacun des 3 stalactites). Il faut donc momentanément s'éloigner de cette fameuse valeur 0.5 le temps de passer sous les stalactites pour y revenir aussi vite que possible en modifiant le 2ème paramètre du premier morceau de courbe placé après un passage étroit.

Une observation grandement facilitée par l'utilisation de l'interface graphique m'a permis de comprendre que state[0] contient la position horizontale à la fin du dernier morceau de courbe placé (la cave est en fait divisée en 128 "tranches verticales" qui donnent une abscisse comprise entre 0 et 127, stockée dans state[0]), de même state[1] contient la position verticale, state[2] contient un paramètre toujours compris entre 0 et 1 et qu'il vaut mieux conserver à 0.5 lorsque c'est possible (c'est le 2ème paramètre des commandes modifier_vol(n1, n2, n3) qui modifie la valeur de state[2]) et state[4] contient la consommation totale (donc le score). Pour state[3], je ne sais pas... J'ai également observé l'évolution de la consommation suivant la valeur prise par state[2]. Si state[2] vaut 0.5, alors chaque nouveau morceau de courbe placé (et qui conserve le fait que state[2] vaut 0.5) consomme 10 s'il est droit (1er paramètre égal à 0) et 20 s'il est courbé (1er paramètre non nul) et ce peu importe sa longueur (donnée par le 3ème paramètre). Si state[2] ne vaut pas 0.5, alors le calcul est différent et la consommation d'un morceau de courbe placé augmente de 3 lorsque sa longueur (3ème paramètre) augmente de 1. L'utilisation de l'interface graphique m'a permis de comprendre que le 2ème argument pouvait se contenter de prendre pour valeur 0.5 ou -0.5, en effet les valeurs strictement comprises entre -0.5 et 0.5 ne sont pas très productives et les valeurs en-dehors de cet intervalle ne changent rien du tout par rapport à un -0.5 ou un 0.5) ce qui a grandement augmenté l'efficacité de mon algorithme de recherche puisque la partie coord2[rang2]+=0.01*(int(0,2)-1) est devenue coord2[rang2]=0.5*(int(0,2)-1) avec seulement 3 valeurs possibles pour chaque 2ème argument.
Donc, pour minimiser la consommation globale, il faut essayer de garder state[2] à 0.5 en modifiant la valeur du 2ème paramètre, ou revenir à ce 0.5 dès que possible. Il faut également minimiser le nombre de commandes modifier_vol(n1, n2, n3) car chaque nouvelle commande a un coût fixe. Il faut donc favoriser de longs morceaux (traversant le plus grand nombre possible de "tranches verticales", peu importe la position verticale (state[1]) de départ et d'arrivée), si possible en ligne droite.

Un dernier point : les collisions. Chaque collision consomme 7 ou 14 (ou plus). Il faut donc à tout prix réduire le nombre de collisions. Il est possible de parcourir la grotte sans collision à l'exception du passage sous le 3ème stalactite. Ce passage entraîne 4 ou 5 collisions dans la plupart des cas. En fait, j'ai modifié mon algorithme de recherche pour l'orienter sur l'optimisation de ce nombre de collisions et surtout j'en ai demandé l'affichage. Le nombre de collisions est calculé deux fois dans chaque "tranche verticale" de cave et prend la forme d'un nombre entier compris entre 0 et 12, inclus. J'ai créé une liste (colli) qui contient ces nombres de collisions et ça donne une liste de 255 entiers compris entre 0 et 12, inclus.
Une de mes tactiques pour améliorer mon score a été de minimiser ma consommation sans prendre en compte le nombre de collisions, puis de modifier mes 3 listes de coordonnées pour réduire le nombre de collisions lors du passage sous le 3ème stalactite puis de réduire le nombre de collisions après le 3ème stalactite. N'ayant d'abord pas utilisé l'interface graphique de Pavel, j'ai tenté d'optimiser le début du parcours (quitte à casser la suite du parcours), puis le passage sous le 3ème stalactite (quitte à casser la suite du parcours) puis de corriger la fin du parcours, et tout ça en jouant sur les valeurs de la liste colli qui contient le nombre de collisions tout au long du chemin parcouru. J'ai ainsi créé un 2ème algorithme ayant pour seul but de réduire le nombre de collisions sous le 3ème stalactite. En fait, dans la liste colli, le passage sous le 3ème stalactite correspond aux 169 et 170ème valeurs (donc d'indices 168 et 169). Dans l'idée, j'ai lancé mon script en mettant comme condition de réussite/affichage le fait d'avoir les 168 premières valeurs égales à 0, donc avec aucune collision avant le passage critique, puis comme condition d'avoir la somme colli[168]+colli[169] (écrite sous la forme sum(colli(168:170]) dans mon script) égale à 4 (en fait 2+2), puis comme condition d'avoir les derniers termes de la liste colli tous égaux à 0.
J'ai tenté à de très nombreuses reprises d'avoir strictement moins de 4 collisions sur le parcours complet, mais rien n'y a fait, ni avec mon algorithme de recherche, ni avec la version adaptée pour la réduction du nombre de collisions, ni avec l'interface graphique de Pavel améliorée par LeGmask je n'ai réussi à réduire le nombre de collisions strictement en-dessous de 4.

Le 26/10 j'ai finalement obtenu 220.0 avec 4 collisions en tout, puis 221.0 mais avec 5 collisions. En supprimant cette 5ème collision, j'ai finalement obtenu 214. Le 27/10 Pavel envoie un score à 211 que j'ai réussi à obtenir quelques heures plus tard en imitant son trajet, sauf pour la fin. (On peut en effet remplacer deux segments droits qui coûtent 10 et 10 lorsque state[2] vaut 0.5 par un morceau courbé qui coûte 10+10 directement). En partant du trajet à 214.0, il restait une optimisation à faire, qu'il a faite avant moi. Bien joué ! J'ai passé de longues heures à essayer de réduire encore le score, pour éventuellement passer à 208 en raccourcissant un morceau courbé dans un passage étroit (donc sans avoir state[2]=0.5) et en rallongeant un segment droit, mais sans succès. J'ai également essayé de réduire le nombre de morceaux (-10 ou -20) tout en ayant une collision supplémentaire (+7 ou +14) mais sans y parvenir. 211.0 est peut-être le meilleur score possible, après tout...
En dégradant ce 211.0 j'ai obtenu 213.98 puis 213.56 puis 213.5 (justement en modifiant le 2ème paramètre du morceau qui contient la portion en rouge et en le mettant à 0.25 plutôt qu'à 0.5, le trait est moins fin mais donne toujours 4 collisions et la consommation globale est alors de 213.5). Il m'a semblé impossible d'obtenir un score strictement compris entre 211.0 et 213.5 et mon algorithme n'a pas trouvé non plus. Le participant qui est juste derrière moi a obtenu 213.501 et le suivant 213.502. En fait, il est possible d'obtenir des scores compris entre 213.500 et 213.501. Par exemple, en mettant 0.2501 plutôt que 0.25 au 2ème paramètre du morceau de courbe qui contient la zone en rouge, on obtient un score à 213.5002 et en mettant 0.25001 on obtient 213.50002

(message original)

1. Pavel () : 211 (Programme : q103.py)

J'ai commencé par modifier le code cave.py pour en faire une version interactive qui peut être contrôlée avec les touches du clavier:
https://gitea.planet-casio.com/Pavel/cavegui

En jouant avec cette version interactive, j'ai essayé de comprendre le comportement du système. Voici ce que j'ai appris:

• il y a trois paramètres à contrôler (l'accélération verticale, le changement de forme du ballon, la durée)
• la vitesse horizontale est constante
• les mouvements à vitesse constante et avec la forme initiale du ballon sont gratuits
• pour le deuxième paramètre, seules trois valeurs doivent être utilisées: 0, 0.5, -0.5
• quand le deuxième paramètre est -0.5, la duree doit etre 1
• il faut minimiser la quantité d'instructions avec l'accélération ou le changement de forme du ballon différent de zéro
• il faut minimizer la durée de deplacements avec la forme du ballon différente de sa forme initiale
• il faut minimizer la quantite de collisions

Regarder des images des solutions des autres participants m'a aussi aidé à apprendre quelques astuces.

Comme il est très facile d'obtenir de bons scores simplement en jouant avec la version interactive du code, je n'ai même pas essayé de coder un algorithme qui trouvera la solution automatiquement.

(message original)

Conclusion

Ce défi est pas mal de grind, avec peu de possibilités d'optimiser le résultat à l'ordinateur (ou en tous cas, pas assez de compétition pour vous inciter à le faire). La précision des passages fait quand même qu'un plan visuel ne suffisait pas à s'en sortir, il fallait aussi traiter chaque collision prudemment tout en limitant le nombre d'instructions.

Personnellement je suis partagé entre ce genre de format et ce qu'on trouve au troisième défi avec de l'IA à programmer. D'un côté jouer directement sur la calculatrice est plus accessible, d'un autre les sujets « paramétrés » (on donne une famille d'instances à résoudre) offrent beaucoup plus de liberté. Qu'est-ce que vous en pensez, vous ?

En tous cas, merci infiniment à tous les participations pour vos envois et vos commentaires. On se retrouve bientôt pour les résultats du défi du Léviathan !

[Wistaro]

Coucou !

Après plusieurs mois de lancement en bêta-test, il est temps de lancer officiellement notre serveur Discord !

Discord, c'est quoi ?

C'est un logiciel cross-plateforme de communication écrite et orale, pensé pour rassembler des communautés.
Organisé sous forme de serveurs, il possède de nombreux avantages :

• Possibilité de créer des channels écrits et vocaux rassemblés par thématique pour une organisation optimale ;
• Possibilité de partager son écran (même sur mobile) ou sa webcam à plusieurs personnes, très simplement ;
• Synchronisation sur toutes les plateformes (Windows, Android, Linux, MacOS, iOS...) ;
• Possibilité d'inviter des bots tiers permettant d'ajouter de très nombreuses fonctionnalités.

Pourquoi un serveur Discord TI-Planet ?

Discord possède de nombreux avantages que le forum et le tchat de TI-Planet n'ont pas forcément. De plus, une grande partie des visiteurs utilisent quotidiennement Discord: c'est un réseau très prisé par la majorité des visiteurs de notre site.
Le but de ce serveur Discord n'est pas de remplacer le forum ou la shoutbox, mais simplement d'ajouter un espace de discussion alternatif et instantané pour que la communauté TI-Planet puisse échanger de manière moins formelle sur des sujets plus libres.

Que retrouve-t-on sur ce Discord ?
Grâce au travail d'Adriweb et de moi-même, le serveur Discord est étroitement lié au forum de TI-Planet pour que les deux ne forment qu'une seule entité.

Vous y retrouverez donc :

• un channel qui poste toutes les news postées sur TI-Planet. De plus, vous pouvez aussi "suivre" ce channel, c'est à dire recevoir l'annonce des news sur votre propre serveur Discord.
  Libre à vous également d'activer les notifications sur ce canal pour être informés dès la sortie d'un nouvel article ;
  
  
  
  
  
• de la même manière que pour les nouveaux articles, un channel envoie une notification pour tous les nouveaux messages postés sur le forum ;
  
  
  
  
• un channel spécial est lié à la fois au tchat de TI-Planet et au canal irc #tiplanet. Tous les messages postés sur Discord, sur le tchat ou sur IRC sont synchronisés et affichés simultanément sur les trois plateformes.
  C'est plutôt pratique, si vous êtes plutôt adepte d'un moyen de discussion particulier et que vous ne souhaitez rater aucun message posté ailleurs !
  
  
  
  
  
• des salons de discussions écrits et vocaux où vous pouvez parler de tout et n'importe quoi, tant que ça reste "sfw" (non sexuellement explicite) et dans le respect des règles ;
  
  
  
  
• un espace dédié aux jeux vidéos, pour celles et ceux qui souhaitent discuter et jouer avec les autres à leur jeu favori ;
  
  
  
  
• d'autres salons existent, je vous laisse les découvrir.

Comment le rejoindre ?
C'est très simple : il suffit de cliquer sur CE LIEN, que vous soyez sur pc ou sur mobile! Sur ordinateur, il n'est pas obligatoire de télécharger le logiciel : il fonctionne également via votre navigateur web.

N'hésitez pas à me faire part de vos suggestions pour améliorer le Discord !

Bonne visite du serveur !

[Lephe]

Salut à la communauté TI-Planet ! On se retrouve aujourd'hui pour analyser et classer les participations à notre Défi Python de Xuanwu, le premier défi de du concours de rentrée 2020 !

Nous avons reçu 154 participations de 28 personnes, le plus grand nombre de personnes individuelles et second plus grand nombre de participations toutes éditions confondues. Là-dedans, 6 personnes se sont placées dans la guilde Planète Casio et 16 dans la guilde TI-Planet. Merci à tous ! o/

L'objectif de cette épreuve était de parcourir un labyrinthe en consommant le minimum d'énergie à l'aide d'un véhicule programmable. Les modalités ont été détaillées par Hackcell dans un topic d'entraide si vous voulez voir les détails ; les principaux éléments sont les suivants :

• Les contrôles disponibles sont de la forme avancer, tourner à gauche et tourner à droite.
• Il y a un coût fixe pour chaque action.
• Il y a aussi un coût sur le nombre de décimales des valeur spécifiées : avancer(1.3937) coûte plus cher que avancer(1.4).
• Il y avait plusieurs chemins et les chemins plus longs recevaient un petit bonus pour équilibrer.

Voyons voir ce que vous avez réussi à trouver avec ces règles ! Nous avons rédigé quelques commentaires pour chacune de vos participations, n'hésitez pas à ajouter des détails sensationnels et autres techniques secrètes dans les commentaires.

Le classement

26. KikooDX () : 320011.24538193 (Programme : x37.py)

Notre première participation est de bien des façons également la meilleure. Voyez-vous, il y a un secret dans ce labyrinthe. Si vous tournez de 2⁹ radians vers la droite tout en avançant de 1337 pas entre chaque rotation, vous serez emmené·e tout droite à la sortie ! Définitivement la méthode la plus élégante !

Au fond cette technique reflète bien l'usage quotidien des calculatrices de niveau Lexibook, et ça se voit puisque le score final s'approche du rapport prix/qualité de la machine. x3

25. Anonyte () : 161.84356628353 (Programme : x18.py)

La participation suivante nous vient d'Anonyte. Personne n'a eu de mal à situer, vu le calcul du score, que les chemins ayant le moins de segments seraient les moins chers à autres facteurs égaux. On attaque donc avec un chemin de longueur 11, des angles et longueurs ajustés à la main - les angles au dixième, parfois au centième.

Ce score de 161 représente une amélioration de 99.949% par rapport à la participation précédente, la plus grosse séparation de toute l'épreuve.

24. OulanB () : 138.59776036691 (Programme : x38.py)

En ajustant les longueurs au dixième également, OulanB évite les collisions avec les murs, qui sont lourdement pénalisées sur le score. On gagne immédiatement 23 points sur le résultat. Dans l'ensemble tout le monde a fait attention à ne pas croiser les murs quitte à s'arrêter au milieu des couloirs.

23. Arm234 () : 132.33617133049 (Programme : x84.py)

Le programme d'Arm234 est le premier à utiliser un chemin de 10 segments. Les longueurs sont ajustées au centième, ce qui ajoute entre 10 et 20 points, mais l'économie d'un segment (une orientiation à 5 points et un mouvement à 8 points, plus les décimales) permet de compenser. Ce qui montre bien que la première étape devait être de trouver le chemin le plus court sans se soucier du calcul des décimales.

22. M4x1m3 () : 105.42754591515 (Programme : x20.py)

Ce parcours de M4x1m3 est certainement le plus tordu de toutes les soumissions ! Malgré un bon détour, il atteint un score de 105 points. J'admets ne pas être certain de comment il en arrive là.

21. Robin M. : 104.18973099423 (Programme : x107.py)

Le chemin emprunté par Robin M. est le seul à passer par la ligne supérieure. C'est un passage que j'avais envisagé en ajoutant le bonus pour les chemins plus longs. Il n'est pas très compétitif (malheureusement ce problème laisse peu d'espace aux variations sur le chemin), mais ça reste une bonne approche qui s'avance très près de la barre de 100 points.

20. Darks () : 91.41917680793 (Programme : x52.py)

Avec Dark Storm on arrive au point du classement où tout le monde utilise la même technique de sortie. Ce zig-zag final permet d'éviter des tours et cache encore une surprise que le top 13 a su s'approprier. C'est aussi la dernière participation à 10 segments et la première en-dessous de 100 points. Le point d'équilibre parfait !

19. CaptainLuigi () : 81.601629520489 (Programme : x146.py)

C'est ce chemin qu'on découvre avec CaptainLuigi, à 9 segments, qui est utilisé par le plus de participants : 10 en tout. On est tout juste avant la limite de 80 de score et l'optimisation s'apprête à descendre dans les fins détails de distance, de décimales sur les angles, et de décimales sur le score.

18. bebertii () : 76.379566366772 (Programme : x123.py)

Avec le même chemin que le CaptainLuigi, mais 4 décimales de moins dans la spécification des angles et des longueurs, bebertii inaugure la catégorie 70-79 de score, qui est la dizaine finale. Aucun chemin soumis ne produisait un score en-dessous de 72 (décimales non comprises). De là à vous dire si c'est possible ou non... je vous laisse émettre les hypothèses.

17. Afyu () : 76.000906078003 (Programme : x64.py)

Ce chemin est l'alternative à 9 segments. La plupart des meilleurs scores se sont battus entre cette version et celle des deux soumissions précédentes. La différence n'est pas énorme, mais c'est intéressant de voir alterner les formes au fur et à mesure qu'on monte en score. J'ai tenté d'équilibrer le score pour qu'il y ait plus d'un chemin optimal mais ce sont les deux qui tiennent la compétition.

Si vous avez regardé le code de génération, c'est ce que Wikipédia appelle le fusion aléatoire de chemins sauf qu'on continue de retirer des murs une fois le labyrinthe connexe, justement pour qu'il y ait plus de solutions.

Afyu nous a même donné une explication de sa méthode.

Effectivement, j'ai tout fait moi même, mais sans décortiquer le script, donc j'ai raté l'astuce des angles à une seule décimale.
Pendant mes recherches, au début, j'ai choisi des arrondis, mais pas forcément au dixième

Code: Select all

distance[a]=int(100*distance[a]+1)/100

simplement parce que l'écriture avec un grand nombre de 9 après la virgule (dû à la méthode de calcul en binaire des ordi) des nombres déterminés par mon algorithme me dérangeait "esthétiquement".
J'ai effectivement le "bon" chemin (aux ajustements d'angles et de distances près) et j'ai également longuement travaillé sur le chemin finalement également choisi par Pavel. J'avais trouvé l'astuce de mettre une dernière distance hors bornes pour améliorer le score, mais ça n'a pas suffi.

(message original)

16. Dubs () : 74.750056119786 (Programme : x139.py)

La participation de Dubs est la seule rendue sur HP Prime. Pour rappel, le calcul des collisions et du score est fait purement formellement, et n'est pas impacté par l'affichage. Donc la notation est indépendante du modèle (sauf cas pathologiques de résultats de calcul en flottant). Notez qu'on revient au premier chemin de 9 segments.

15. cent20 () : 73.04042664132 (Programme : x102.py)

Alors qu'on se rapproche de la barre fatidique des 72, on repasse sur le chemin alternatif de 9 segments. À ce stade tout le monde limite au maximum l'utilisation des décimales, que les solutions soient optimisées à la main ou pas.

L'idée de compter les décimales vous surprendra peut-être. L'intuition c'est que si on autorise des nombres quelconques sans pénalité, il devient beaucoup plus facile, une fois qu'on a une idée générale du chemin à prendre, de calculer les angles et les longueurs qui optimisent la distance parcourue, le total d'angle parcouru, ou à peu près n'importe quelle métrique de votre choix.

De façon générale, les problèmes sur les réels sont plus faciles que les problèmes sur les entiers. Cette contrainte visait à vous empêcher de calculer les optimaux avec un programme en trois clics. Même si, vous le verrez à la fin du classement, ça s'est retourné contre moi puisque la pénalité était trop forte et du coup le nombre de valeurs viables (à 0.1 près) était faible, ce qui a permis à certains candidats de faire du brute-force.

14. grandben49 () : 73.003909873986 (Programme : x137.py)

Vous remarquerez que tout le monde ne fait pas le zig-zag final de la même façon. Certains le prennent de façon plus serrée, comme grandben49, alors que d'autres en font des paquets pour faire le long aller-retour possible. Ça vient du bonus attribué aux chemins les plus longs. Il n'y a de coût que pour utiliser les fonctions et spécifier des décimales. Une fois le nombre de segments fixé, c'est plus rentable de parcourir le plus de longueur possible pour minimiser le score.

13. Ne0tuX () : 72.747717453626 (Programme : x150.py)

Ne0tux est le premier dans ce classement à avoir utilisé le bonus de longueur (qu'il a remarqué de justesse) lors de la sortie du labyrinthe. Voyez-vous, pour une raison complètement intentionnelle que j'avais absolument prévue et validée durant les tests, le programme continue de vous faire avancer une fois que vous avez passé la sortie.

Du coup, si vous prenez un angle rasant pour sortir du labyrinthe le plus à l'horizontal possible, le chemin peut se prolonger sur un bon paquet de cases avant d'atteindre le mur fixé en bas de l'écran. Tout ce parcours supplémentaire s'ajoutant bien entendu au bonus de longueur, ce qui permet de réduire le score final.

Bravo à tous ceux qui s'en sont rendus compte à la lecture du code.

J'ai procédé de façon un peu originale ; une réminiscence des défis de dessin des années précédentes. J'ai commencé par lire le code puis confirmer certaines intuitions via la GUI de Pavel. Puis j'ai téléchargé le code sur mon smartphone et imprimé le labyrinthe sur papier, avant de partir pour 15 jours de congés sans PC ni Wifi. Avec mon bout de papier, une règle, un rapporteur et la volonté de faire un nombre minimal de traits les plus longs possibles et passant par le centre des "portes", j'ai pu tracer une sorte de "couloir des possibles".

J'en ai testé plusieurs sur smartphone (sans GUI) et validant ma solution finale via la version Oméga en ligne. Comme comparer était fastidieux depuis mon petit écran, je n'ai pas cherché plus loin que le 1e digit pour la rotation (ça tombe bien, il fallait le moins de digit possible). Sauf sur l'un des premiers points, ce qui explique que je sois resté à 72. Pour la longueur des segments c'était moins drôle car la mesure sur mon papier ne correspondait pas : souvent on pouvait approcher un mur, augmenter la longueur et quand même diminuer le score. J'ai bien faillit ne pas le voir !

La seule "optimisation" scriptée pour moi concernait la longueur et l'orientation des deux derniers segments, pour aller chercher un x en dehors du labyrinthe le plus loin possible.

(message original)

12. jacobly () : 71.056893450111 (Programme : x31.py)

Une autre participation qui se démarque est celle de jacobly, qui n'utilise... que des entiers. Vous avez bien entendu : un peu d'imagination, une bonne heure de recherche et une calculatrice lui ont visiblement suffit pour passer sous la barre des 72. Je vous cache pas que je m'y attendais pas à celle-là.

Not much to say about my method, just spent about an hour finding the shortest path with the original program, and couldn't be bothered optimizing floating-point error for the update.

(message original)

11. Filoji () : 71.018891561397 (Programme : x96.py)

Certains de ces commentaires sont très complets donc je vous laisse avec les explications.

1 - Découverte
C'était la catastrophe, entre le topic d'entraide et les calculs incompréhensibles, je me disais que c'était peine perdue... Mais j'ai persévéré, et ai trouvé enfin le premier chemin ! (142 pts)
Bon, après j'ai continué et j'ai trouvé mieux (120 pts)

2 - Le sub 100
Je rejoins PC et Casio pour avoir la meilleur équipe (Parce que Lexibook )
Grâce à Bzh, j'ai trouvé le bon chemin (Il avait fait ça à l'arrache sur Gimp), et je trouve mes 1ers sub 100 !!! (88 pts)
Ensuite, Pavel nous partage son outil pour améliorer notre score, et je m’améliore encore (75 pts, 72 pts)

3 - La course aux décimales
C'est bon, j'ai compris la technique... Mais quelques heures trop tard !
J'arrive ex aequo avec toute les personnes de ce rang, et je cherche alors à faire le moins augmenter mon score pour pouvoir trouver un score unique
Ça y est, j'ai trouvé, Merci Pavel, j'ai séché ton programme pour enfin trouver les 71,01889156139690 et les 200 unités de déplacement pour optimiser le plus ma consommation

Fin, voilà, c'est pas extraordinaire, mais c'est moi qui l'ai fait

(message original)

10. TIny_Hacker () : 71.000399584431 (Programme : x151.py)

Pas mal de gens ont utilisé l'interface graphique de Pavel pour faire leurs tests. Critor et moi avions une version SDL2 de polycalc.py pour tester rapidement sur PC (... même si Critor a enduré la mise en compatibilité avec tous les modèles), mais Pavel a carrément créé un outil interactif pour explorer le labyrinthe. Alors tout de suite les scores sont descendus pas mal.

Voilà une image de l'explorateur interactif de Pavel, puis l'explication de TIny_Hacker.

Honestly, I only did this well because of Pavel's GUI, which allowed me to test my ideas faster than manually typing them out, and to tweak things as I went. I started by figuring out on paper what path had the fewest number of segments and went from there. Eventually, I discovered that shortening the decimal on turns would decrease the score, and finally that adding a 0.000049999 (or something like that) could decrease the score without changing the path itself. Afterward, I just messed around till I got as low of a score as I could. That's about all there was to it!

(message original)

9. dvon () : 71.000243500836 (Programme : x152.py)

Pour sa part, dvon a utilisé un algorithme aléatoire, visiblement en déplaçant au hasard les angles de quasi-multiples de 2π le long du chemin pour obtenir un meilleur score. Le sujet imposait des limitations pour éviter ce genre de méthode, bravo pour les avoir contournées !

Cette participation est la première à utiliser des variations d'angle et de distance inférieures à 10⁻⁵. En effet, à cause de différences de calcul d'une machine à l'autre, il a fallu faire pas mal de compromis sur l'évaluation du nombre de décimales. Un de ces compromis était d'arrondir à 5 chiffres après la virgule... ce que les participants observateurs se sont empressés d'utiliser à leur avantage.

For my solution, I started with the GUI shared by Pavel. I added code to try to automatically tweak argument values to get lower scores. But this didn't help, because (as I figured out eventually) the best scores were always from the values with only one digit after the decimal point.

In the end I used a version of the GUI modified just a little bit. I added code to output a record of scores for everything I tried a long a path, so that I could make sure I was doing at least as well in the current attempt as in previous attempts, and I made it possible to tweak angle and distance arguments by +-0.000004 units (and not round
the tweak away), since this slight difference wouldn't affect the part of the score based on the number of characters needed to represent the value. Also, for each turn I experimented with adding or subtracting a full rotation (i.e., about 2pi but not exactly because of the 1/10 increments) and was able to avoid using any angles that would be treated as 4-character values in that part of the scoring.

(message original)

8. Ruadh () : 71.000066133741 (Programme : x112.py)

Déjà top 8, et on arrive sur la première optimisation à coup de sinus. Un des problèmes des toutes premières versions du script c'est que seul le coût des déplacements était pris en compte. Ce coût est entier, il n'y a donc rien à exploiter entre 71 et 72... ce qui aurait fait beaucoup trop d'égalités.

Du coup j'ai proposé de faire la modification arbitraire d'ajouter au score le sinus de la somme des longueurs et angles utilisés durant le parcours. C'est fourbe parce que comme les participations sont limitées à peu de décimales, il n'est pas facile d'atteindre les valeurs minimales du sinus, qui se situent sur des demi-multiples de π. Par chance, 11 est presque égal à 3.5π donc il était possible d'avoir un sinus de presque -1 et donc d'arriver à presque 71.

En lisant le programme, j'ai pu apprendre qu'il fallait :
- minimiser le nombre de virages
- ne pas foncer dans les murs
- parcourir une distance d'au moins 200
- utiliser des distances et angles avec au plus une décimale

J'ai donc cherché manuellement un chemin qui respecte toutes ces propriétés et j'ai obtenu un score aux alentours de 72. J'ai ensuite remplacé certaines rotations afin de minimiser le sinus (tourner à gauche de α revient à tourner à droite de -α) et j'ai obtenu le score 71,00001411857056 que beaucoup de personnes avaient déjà obtenu. J'ai donc à nouveau modifié les rotations pour avoir un score plus élevé.

(message original)

7. Alice () : 71.000014118571 (Programme : x88.py)

Hackcell résume superbement l'intégralité des règles et techniques utilisées jusqu'ici.

Alors, j'ai vraiment procédé étape:

- Premier jet à la R.A.C.H.E (iso-1664) qui me donne dans les 150 points
-Lecture du code et écriture d'un topic sur ce dernier, je me rend donc compte qu'il faut minimisé le nombre de virage et maximiser la distance (dans la limite des 200 unité arbitraire)
- j'obtient donc un score d'environ 93.
- je me rends compte que l'on peut continuer une fois sortit du labyrhinte, ce qui facilite la maximisation de la distance, je descend a un score de ~83 (si continuer ainsi n'avais pas été possible, l'epreuve aurait sans doute été beaucoup plus challenging, mais c'etait fun quand même)
- grâce a ma connaissance du code, je me rends compte que le seul moyen de descendre c'est de supprimé un virage ou faire disparaitre les décimales. Or le meilleur score actuel est de 72 ce qui correspond au score que j'obtiendrait si j. supprimais ces decimales, je recherche donc de ce cotés, et bingo, 77, puis le fameux 72.
- enfin presque, entre temps il y a une régles en plus, on reçoit des points en fonction du sinus d'une fonction assez simple a manipuler, le seul probléme c'est que pour supprimé les décimales on se retrouve a se balader de 0.1 en 0.1 sur cette fonction, ce qui n'est pas l'idéal pour la minimiser, je test donc plusieur valeurs , change des virages a droite de theta par des a gauche de -theta, tente de continuer aprés la sortie pour explorer cette fonction en restant dans les conditions optimales (9 virages, pas plus d'une décimale) et finis avec un 71,000…
Je décide alor de m'arreter là jusqu'a ce qu'un score qui signifirais 8 virages soit trouvé, ce qui n'est pas arrivé.

(message original)

6. Ti64CLi++ () : 71.000013644375 (Programme : x153.py)

Malgré l'utilisation d'un bon vieux sinus pour tenter de faire sortir des scores différents à tout le monde, Ti64CLi++ s'est retrouvé plusieurs dans la situation de devoir ajuster ses scores pour éviter de créer des égalités (qui étaient interdites). Les plus rapides y trouvent leur compte... cela dit je veut bien donner un cookie à qui saura produire une égalité sur le défi du Léviathan sans se concerter !

Alors, j'ai vraiment tout fais à la main.

J'ai commencé par tester le programme et voir quel score je pouvais obtenir comme premier jet, et c'est ainsi que j'ai envoyé mon premier score de 148.

Ensuite, j'ai vite compris que moins il y avait de segment, et plus ceux-ci étaient long tout en minimisant le chemin, meilleur le score était. Après plusieurs essais, j'ai donc obtenu les scores de 133 puis 99 puis 80. Entre temps, j'ai du donc changé de chemin pour descendre à 9 segments.

Là j'ai commencé à bloqué, puis une première lecture du code m'a permise de me rendre compte que les chiffres significatifs jouaient un rôle important dans le calcul du score. J'ai donc cherché un moyen de passer à un unique chiffre après la virgule. J'ai ainsi baissé mon score à 74 puis 73 puis 72.

Encore une fois, j'ai un peu galéré, mais après 1h de différents tests sur le même chemin, j'ai enfin passé la barre fatidique des 72. Il restait encore quelques améliorations à faire, mais après quelques changements minimes, je suis arrivé à mon score de 71.000014.
Tout ça pour me rendre compte plus tard dans la journée après mise à jour des participation, que Tituya avait envoyé le même score quelques 40 minutes plus tôt.
J'ai donc baissé mon score du minimum que je pouvais, et j'ai envoyé mon 71.00554.

Je suis resté sur ce score jusqu'à ce que _iPhoenix_ descende en dessous de moi, et me propose de m'aider si vraiment je coince. Il me dit donc de regarder attentivement la fonction cout, à laquelle je n'avais pas vraiment fait gaffe.
Après quelques réflexions et tests avec Python, je me suis aperçu que je pouvais encore baisser mon score en jouant sur les chiffres à 5 ou plus positions de la virgule à droite.
J'ai donc aisément réussi à baisser mon score en appliquant cette technique et j'ai obtenu 71.0000139, parce que comme un débile je n'ai appliqué ça qu'aux distances et non aux angles. Tout ça pour me rendre compte que, encore une fois, Tituya, n'avait lui pas fait cette erreur, et par la suite avais soumis un score de 71.0000136.

Enfin, quelques heures (pratiquement 2h tout pile) avant la fin du concours, j'ai retrouvé un peu de motivation, et me suis donc assuré la 6ème place en appliquant cette fois-ci la méthode aux angles. J'ai donc envoyé mon score de 71.00001364437452.

(message original)

5. Tituya () : 71.000013644375 (Programme : x141.py)

Le top 5 est excessivement complet dans ses explications, donc je leur laisse la parole !

On commence doucement avec une première tentative à 152. Ce score a bien chuté depuis

À la toute première approche je n'ai absolument rien testé de précis, j'essaye simplement de voir à la main ce que je peux produire et comment contrôler cette machine mystique.

Un peu de lecture, ça ne fait pas de mal :

Je comprends cependant très vite que nous devons améliorer le nombre de virages pour changer la valeur du score. Je remarque en même temps que l'instruction `a_gauche` semble être plus rentable que sa compère `a_droite`.
Et en effet, cela me permet bien de diminuer mon score.

Je continue ma lecture du code. Nous avons une distance maximale possible de 200. Qui donne un bonus considérable sur le score final, il faut donc maximiser celui-ci !

L'art du bourrinage :

Dans une envie soudaine, je programme un code de bruteforce me permettant de trouver théoriquement le meilleur score possible. Je me rends vite compte que la vitesse de python et le nombre de calculs à faire rend juste impossible cette procédure

Je lance quand même ce script pour optimiser les 3 premiers virages. Qui me donne des résultats plus que corrects !
Je lance ainsi de suite des optimisations grâce à ce script d'une succession de virages. Ce qui m'amène à ce fameux score assez commun de 71,00001411857056

Puis je bloque.

Je pars en freestyle pour voir ce que ça donne :

Mais au bout d'un moment je me demande si je ne peux pas rajouter des 0 ou des 9 un peu partout sans aucune logique peut me permettre de descendre.
Dans ma tête, le principe est simple :
Il faut limiter au maximum la distance totale tout en gardant le score[6] à 200.

J'essaye, ça marche correctement... Super !

Puis j'essaye des valeurs de plus en plus précise pour voir si ça change quelque chose, je me rends compte qu'en dessous de x.x99995, mon score descend.
J'optimise donc à la main chaque virages pour enfin arriver à mon score final : 71,00001364437450

Des tentatives théoriques

À partir de là, un peu de théorique. La précision des virgules est géré par le total (virage + distance). Je calcule alors ce que je dois enlever pour obtenir un score maximal.

Je n'ai cependant jamais réussi à trouver ce score... Peut-être qu'il est d'ailleurs impossible à avoir
Donc j'arrive avec ce magnifique score qui me donne la chance d'être 5e dans ce concours !

(message original)

4. LeGmask () : 71.000009639162 (Programme : x149.py)

Spoiler: j'ai tout fait a la main
Dans les faits la plupart de mes outils mon fait perdre plus de temps qu'autre chose, après nombreuse tentative je suis descendu a 100 et des brouettes et y suis resté bon nombre de temps, j'ai fini par craquée et est demandée des indices a _iPhoenix_
C’est là que le massacre commence, de 1 j’avais pas le bon chemin, et de 2 j’avais des angles a 2 décimales …

Après quelque heure de recherche je finis finalement par descendre a 71,…14… sauf que spoiler, vu que je m’y suis pris encore une fois 3 mois après la course, le score était pris :notlikethis:
À ce point obligé de détériorer mon score afin de publier pour la première fois mon résultat.

Le cours de philo qui suit ne ma pas porter conseille et encore une fois _iPhoenix_ ma sauvée la mise avec un précieux indice, j’avais compris le code de l’arrondis, mais pas totalement vu que je n’avais pas pensée au tout petit décimal qui pourrait optimiser le tout encore plus 😊

Finalement je descends et me place en 6e position, là j’ai beau essayée tout ce que je peux je ne comprends pas, comment descendre beaucoup plus, puis encore une fois un indice sur le sinus par _iPhoenix_ ma remis sur le pied de guerre, j’ai donc cherché et vu qu’on pouvait descendre sur le sinus de 11 beaucoup plus proche de -1, la avec les décimaux j’ai pu descendre mon score et me placer 4e
Dans tous les cas je remercie grandement _iPhoenix_ pour tous ces petits conseils, sans lui je ne saurais sans doute pas là, et je reste une grande arnaque 😊.

(message original)

3. _iPhoenix_ () : 71.000009399186 (Programme : x134.py)

After getting the opencv2 script from commandblockguy, I tried getting a path that worked, not thinking too much about scoring- I ended up with a score that was around 470 or so, not so great: (click any image to enlarge)

After realizing that turning and moving had a fixed cost in addition to their distance, I tried to reduce the number of segments:

This got me to around 86 or so. (One interesting trick I employed was lengthening the last segment out of bounds)

This all happened within an hour or so of me having the code, so I didn't really write or use any tools at this point- there was no need.

I eventually wrote a function that would let me give it points- this took me longer than I would care to admit (my trig is quite rusty). Here it is, in all of its glory:

Code: Select all

def move_to(x, y):
  cur_x, cur_y, cur_angle = state[0:3]
  a_gauche(round(cur_angle - atan2((y - cur_y), (x - cur_x)), 1))
  avancer(round(sqrt((x - cur_x) ** 2 + (y - cur_y) ** 2), 1))

I modified the functions for turning and for moving so they would dump code I could submit into a file- this was a really simple change and was extremely convenient.

For brute-forcing, I just defined a noise function that was easy for me to tweak (for example, changing it to a Gaussian distribution or tweaking the parameters). I mostly used brute-forcing to eliminate decimal places.

Code: Select all

def noise():
  return (random() - 0.5)/10

Throughout this process, commandblockguy was extremely helpful. I did feel a little guilty asking for help, but I made sure to at least drop hints to anyone who asked me in return (which ended up being a decent number of people)

(message original)

2. Pavel () : 71.000009399186 (Programme : x86.py)

Voici une explication de mon approche pour trouver une solution à ce défi.

J'ai commencé par essayer de comprendre comment la consommation est calculée. Voici les parties du code Python montrant tous les composants des calculs de consommation:

Code: Select all

def fix_angle(a):
  return a * 2 * asin(1) / pi

def a_gauche(a):
  global state
  state[7] += a
  state[5] += 5 + cout(a)

def avancer(l):
  global state
  state[7] += l
  state[5] += 8 + cout(l)
  while(l > 0):
    l -= .25
    state[6] += (state[6] < 200)

def aller_selon(f):
  global state
  state = [0, .5, 0, 0, .5, 0, 0, 0]
  f()
  state[5] += sin(fix_angle(state[7])) - state[6] // 2
  print('Consommation : ' + str(state[5]))

Apparemment, la consommation se compose des trois éléments suivants:

• `state[5]` = consommation de base
• `state[6]` = distance totale parcourue multipliée par quatre
• `state[7]` = angle total + distance totale

Ensuite, j'ai testé la fonction 'cout()' qui est utilisée dans les calculs de consommation:

Code: Select all

>>> from laby import *
>>> cout(5)
3
>>> cout(0.5)
3
>>> cout(0.05)
4
>>> cout(5e-3)
5
>>> cout(5e-4)
6
>>> cout(5e-5)
7
>>> cout(5e-6)
3

Il semble donc que la consommation puisse être minimisée en combinant les éléments suivants:

• minimiser la quantité de manoeuvres
• minimiser 'sin(state[7])'
• maximiser la distance totale parcourue
• ne pas utiliser plus d'un chiffre décimal après la virgule décimale
• essayer d'exploiter le faible coût du 'cout(5e-6)'

Pour minimiser 'sin(state[7])', j'ai utilisé le code Python suivant pour créer un tableau montrant les valeurs de la fonction 'sin()' pour différents angles avec un seul chiffre décimal après la virgule décimale:

Code: Select all

from math import pi, sin

l = []

for i in range(-10, 11):
  a = round(-pi/2 + 2 * pi * i, 1)
  l.append((a, sin(a)))

l.sort(key=lambda e: e[1])

for e in l:
  print('a = %5.1f -> sin(a) = %f' % e)

Voici le résultat:

Code: Select all

a = -64.4 -> sin(a) = -0.999996
a = -26.7 -> sin(a) = -0.999994
a =  11.0 -> sin(a) = -0.999990
a =  48.7 -> sin(a) = -0.999986
a =  42.4 -> sin(a) = -0.999934

De petites valeurs de 'state[7]' sont donc nécessaires pour une faible consommation. Vu que 'state[7]' est la somme des angles et des distances et que les distances ne peuvent pas être négatives, alors les valeurs des angles passés à la fonction 'a_gauche()' doivent être négatives.

Une fois que tout ça est devenu plus ou moins clair, j'ai modifié le code laby.py pour en faire une version qui peut être contrôlée comme un jeu vidéo avec les touches haut/bas/gauche/droite sur le clavier: https://gitea.planet-casio.com/Pavel/labygui

En utilisant cette approche, j'ai obtenu la solution suivante:

Code: Select all

from laby import *

def chemin():
  for e in [(-6.6, 2.3), (-7.3, 6.3), (-5.2, 4.6), (-4.8, 4.1), (-7.3, 6.3), (-8.3, 3.8), (-5.1, 3.8), (-2.3, 4.3), (9.1, 13.3)]:
    a_gauche(e[0])
    avancer(e[1])

aller_selon(chemin)

La consommation correspondant à cette solution est de 71.0000097934493.

À ce stade, je n'ai toujours pas exploité le faible coût du 'cout(5e-6)'. J'ai donc essayé d'ajouter ou de soustraire 5e-6 des distances et des angles. La solution qui m'a donné le score le plus bas (71.00000939918644) était la suivante:

Code: Select all

from laby import *

def chemin():
  for e in [(-6.6, 2.3), (-7.3, 6.3), (-5.2, 4.6), (-4.8, 4.1), (-7.3, 6.3), (-8.3, 3.8), (-5.1, 3.8), (-2.3, 4.3), (9.1, 13.3)]:
    a_gauche(e[0] - 5e-6)
    avancer(e[1] - 5e-6)

aller_selon(chemin)

Au moment où j'ai trouvé cette solution, elle était déjà soumise par commandblockguy et j'ai dû trouver la deuxième meilleure solution (71.00000939918645) en ajoutant de très petites valeurs aux angles et aux distances:

Code: Select all

from laby import *

def chemin():
  for e in [(-6.6, 2.3), (-7.3, 6.3), (-5.2, 4.6), (-4.8, 4.1), (-7.3, 6.3), (-8.3, 3.8), (-5.1, 3.8), (-2.3, 4.3), (9.1, 13.3)]:
    a_gauche(e[0] - 5e-6 + 1e-13)
    avancer(e[1] - 5e-6 + 1e-13)

aller_selon(chemin)

(message original)

1. commandblockguy () : 71.000009399186 (Programme : x75.py)

As for my strategy, I basically found a path through the maze by hand that had as few points as possible, without worrying about my score too much. I made sure to take a very shallow angle when exiting so that the path would be long enough to get the maximum score.

I then tested every single combination of angles and distances that would put me within some distance (if I remember correctly, about 1.5 tiles, though I changed it several times) of my original points, while still allowing me to get the maximum score. This was feasible because you get points off for each digit after the first decimal place, or before the units place, which means that there are only 100 angles and 100 distances to try for each point. The exception for this is the last point, which has to be more than 10 units away in order to meet the length requirement. This took a few hours to run in its entirety, and I was left with a few thousand paths. Prior to the scoring change, all of these paths would have left me with a score of 72, but after the scoring change it was now possible to get a fractional score.

A "heatmap" of all the paths I found. The color of each point represents the last "target" point it was able to get to, with purple being the final point, outside of the maze.

The fractional part of the score was determined based on the sine of the sum of the angles and distances, which means that the input to sin() could be no more precise than to the tenths place. For the range of numbers that this sum could possibly be without adding a full point to my score, the tenth whose sine is closest to -1 is 11.0, and sin(11) is = -0.999990207.

Unfortunately, none of the few thousand paths that I had found added up to 11.0. However, I realized that I was only calling a_droite() in my path, and that if I replaced a_droite(x) with a_gauche(-x), x would be subtracted from the sum rather than added to it, without actually changing the validity of the path. I tried out every combination of a_droite and a_gauche calls for each of my few thousand paths, and found one that added up to 11.0, giving me a score of 71.0000097934493.

Here's the code that I used to find this path.

You'll notice that this is still very slightly off from my actual score - I realized that I could slightly decrease sin(sum) by slightly decreasing sum, and that I could slightly decrease sum by subtracting a tiny amount from each distance and angle. Normally, this would cause my score to increase by several full points because of the decimal places after the tenths place, but because the score is rounded to 5 decimal places before the length of the number is calculated, if the difference is less than 0.000005, you aren't penalized. So, I subtracted 0.0000049999... from each distance, to get a sum of 10.99991, a sine of -0.99999060081, and a final score of 71.00000939918644. I believe that this is within a floating-point error of the ideal solution.

Here's the solution that I submitted, for reference.

I actually tested all of this on a computer, as I didn't have my EP with me. I ported polycalc to use cv2 for drawing stuff.

I also tried to submit a few, uh, let's call them gimmicky, solutions. My first instinct was to try an integer overflow, but to my disappointment, Python doesn't actually have those. The numbers, they just keep going.

After that, I tried subclassing the float class so that it would return an empty string. Technically, this wasn't modifying the internal state of laby.py . I could have also returned a custom string class with a modified __len__ method, but in CPython __len__ must return a positive integer, which also gets converted into a regular integer, not one that I could subclass. Interestingly, MicroPython allows you to return a negative length for __len__, so I could have probably gotten a score of negative infinity if the admins didn't shut that idea down .

Finally, I also found a solution that's far better than the others that I decided not to submit since I was already in first. Here's the link if you want to give it a try for yourself.

(message original)

Conclusion

Ce sujet de labyrinthe était assez simple dans son ensemble, mais avec pas mal de subtilités qui ont bien fait ressortir ce qu'on espérait - des solutions de tous niveaux, avec des approches presques toutes différentes et pas mal de fun à la clé d'après vos témoignages.

Mon regret personnel sur cet énoncé c'est l'existence d'une solution unique. J'ai eu plusieurs retours expliquant que l'attrait d'un des défis les plus populaire du concours de rentrée (le défi de Python consistant à constituer une équipe de Pokémon efficace) est l'existence de multiples solutions même au voisinage des meilleurs scores. On a modifié à ce moment-là le deuxième sujet en introduisant un état, la vitesse du ballon. Chaque ordre se construit sur le précédent et donc on ne peut pas optimiser les ordres un à la fois, ce qui rend plus pénible l'exploration de tout l'espace de solutions.

Mais le sujet qui arrive vraiment à éviter ça est le défi du Léviathan puisque l'espace de solutions est formé de programmes et là les solutions seront vraiment toutes uniques. Ce défi est toujours en cours d'ailleurs, allez y jeter un oeil ou deux !

Un immense merci à tous les participants. J'espère que cet exercice vous aura plus, et on se retrouve bientôt pour les résultats du défi du Quetzalocoatl !

[critor]

Pour cette rentrée 2020, tes communautés lycéennes Planète Casio et TI-Planet se réunissent pour te proposer un concours de rentrée exceptionnel autour de ton outil numérique scolaire favori, ta calculatrice graphique.
Un événement que nous tenons encore plus à t'offrir en période de confinement.

Aucune obligation d'achat pour participer et même gagner, grâce aux précieuses ressources gratuites que nous te compilons en fin d'annonce.

Au total 3 défis indépendants, tous en langage Python :

1. Défi de Xuanwu (tracé Python à la tortue), jusqu'au dimanche 18 octobre 2020 inclus avant minuit heure française (GMT+2)
2. Défi de Quetzalcóatl (tracé Python par coordonnées), jusqu'au dimanche 1^er novembre 2020 inclus avant minuit heure française (GMT+1)
3. Défi du Léviathan (Intelligence Artificielle Python), jusqu'au dimanche 13 décembre 2020 inclus avant minuit heure française (GMT+1)

Les défis ont tous été conçus pour être ludiques et abordables. Rien d'insurmontable, à chaque fois nous te fournissons un script fonctionnel sur un maximum de calculatrices Python officielles ou non, script qu'il te suffira tout simplement d'améliorer. Tout-le-monde peut donc participer et gagner !
Les défis sont de plus totalement indépendants, tu peux parfaitement participer et gagner à un défi sans avoir participé aux défis précédents.

Pour te récompenser nous avons réuni diverses calculatrices graphiques Python haut de gamme, mais accompagnées ici à la différence de nombre de goodies introuvables dans le commerce qui te permettront de porter fièrement les couleurs de ton constructeur préféré.

Voici dès maintenant lancé le défi du Léviathan, pour lequel tu as donc jusqu'au dimanche 13 décembre 2020 à minuit moins une, heure d'hiver française (GMT+1).

Les lots ainsi que leur acheminement te sont gracieusement offerts par :

• Casio
• NumWorks
• Texas Instruments
• Calcuso
• Jarrety
• Bernard Parisse de l'Institut Fourier / Université Grenoble Alpes
• Planète Casio / CreativeCalc
• TI-Planet / UPECS
• Hewlett Packard (reliquat dotation 2019)
  
  Show/Hide spoilerAfficher/Masquer le spoiler

  Suite à de lourdes réorganisations au sein de Hewlett Packard en 2019-2020 il n'y a plus de service marketing spécifique à la France pour les calculatrices, nous relevons désormais d'un service gérant de façon unifiée le marketing des calculatrices pour l'ensemble de l'Europe, service de plus sous-traité en externe auprès d'une entreprise en République tchèque chez qui nous n'avons strictement aucun contact ce qui ne facilite pas la chose.
  Des approches auprès de nos quelques contacts par chance encore restants chez Hewlett Packard ne nous ont hélas pas permis d'obtenir jusqu'à présent de réponse autre que l'assemblage d'éléments que nous venons de te communiquer.
  
  Il reste peu de temps, mais nous te tiendrons au courant si jamais la situation évoluait favorablement en cours de ce dernier défi. Et sinon ben tant pis pour Hewlett Packard.
  
  Toutefois tu n'es absolument pas pénalisé·e si tu souhaites participer sur HP Prime cette année. De notre côté le travail a bel et bien été fait, nos scripts de participation restent compatibles avec la HP Prime.

Les 15 participants ayant réalisé les plus petits scores distincts au défi du Léviathan pourront librement choisir et personnaliser leur lot parmi les propositions suivantes, par ordre de classement :

• 2 lots Capricorne ♑ : 1 calculatrice Casio Graph 90+E + 1 pack de goodies Casio + 1 goodie Xcas au choix + 1 pack de goodies TI-Planet & Planète Casio
• 2 lots Bélier ♈ : 1 solution d'émulation Casio au choix + 1 catalogue de produits Casio au choix + 1 pack de goodies Casio + 1 goodie Xcas au choix + 1 pack de goodies TI-Planet & Planète Casio
  
  Show/Hide spoilerAfficher/Masquer le spoiler

  Détail des solutions d'émulation Casio au choix :
  

  • clé USB 8 Go d'émulation permanente au choix, à jour avec 3 émulateurs pour Windows : fx-92+ Spéciale Collège + Graph 35+E II 3.30 + Graph 90+E 3.40
    
    • clé à capuchon Transcend 2019 (7,5 Go de capacité réelle)
    • clé monolithique EMTEC 2020 (7,7 Go de capacité réelle)
  • licence 3 ans utilisable pour l'installation de tout ou partie des logiciels d'émulation suivants :
    
    • fx-CP400 Manager pour Windows / Mac
    • fx-CG500 Manager pour Windows / Mac
  
  
  
  
  
  
• Lot Serpentaire ⛎ : 1 goodie HP au choix + 1 goodie Xcas au choix + 1 pack de goodies TI-Planète-Casio
  
  Show/Hide spoilerAfficher/Masquer le spoiler

  Poster HP : format 59,2×40 cm².
  
  
  
  
  
  
• 3 lots Sagittaire ♐ : 1 calculatrice NumWorks N0110 + 1 pack de goodies NumWorks + 1 goodie Xcas au choix + 1 pack de goodies TI-Planet & Planète Casio
• 3 lots Balance ♎ : 1 couvercle NumWorks au choix + 1 autocollant NumWorks + 1 enveloppe NumWorks ou carte postale NumWorks ou carte de visite-énigme NumWorks au choix + 1 pack de goodies NumWorks + 1 goodie Xcas au choix + 1 pack de goodies TI-Planet & Planète Casio
  
  Show/Hide spoilerAfficher/Masquer le spoiler

  Couvercle NumWorks au nouveau format N0110 protégeant mieux l'écran contre les rayures, mais restant parfaitement utilisable sur l'ancien modèle N0100.
  
  
  
  
  
  
• Lot Taureau ♉ : 1 calculatrice TI-Nspire CX II-T CAS + 1 licence logiciel TI-Nspire CAS élève + 1 pack de goodies TI + 1 goodie Xcas au choix + 1 pack de goodies TI-Planète-Casio
• Lot Lion ♌ : 1 calculatrice TI-Nspire CX II-T + 1 licence logiciel TI-Nspire élève + 1 pack de goodies TI + 1 goodie Xcas au choix + 1 pack de goodies TI-Planète-Casio
• Lot Gémeaux ♊ : 1 calculatrice TI-83 Premium CE Edition Python au choix + 1 adaptateur USB + 1 clavier USB dédié + 1 chargeur mural au choix + 1 housse Wyngs bleue ou film de protection écran Wyngs + 1 pack de goodies TI + 1 pack de goodies TI-Planète-Casio
• Lot Verseau ♒ : 1 calculatrice TI-83 Premium CE Edition Python + 1 gravure texte laser au choix + 1 adaptateur USB + 1 clavier USB dédié + 1 chargeur mural + 1 housse Wyngs au choix + 1 film de protection écran Wyngs dédiés + 1 extension de garantie 6 ans Calcuso + 1 pack de goodies TI + 1 pack de goodies TI-Planète-Casio
  
  Show/Hide spoilerAfficher/Masquer le spoiler

  Détail des calculatrices TI-Nspire CX II-T CAS au choix :
  

  • TI-Nspire CX II-T CAS sous blister version B
  • TI-Nspire CX II-T CAS sous blister version B avec autocollant sceau Comenius Edumedia 2019

  
  Détail des calculatrices TI-83 Premium CE Edition Python au choix pour le lot Gémeaux ♊ :
  

  • TI-83 Premium CE Edition Python sous blister version E
  • TI-83 Premium CE Edition Python sous blister version E avec autocollant masquant sceau Approuvé par les familles 2019

  
  La gravure au laser de la TI-83 Premium CE Edition Python du lot Verseau ♒ est effectuée par Calcuso. Le texte souhaité est à nous communiquer par le gagnant choisissant ce lot, dans la limite de 22 caractères et sans caractères spéciaux.
  
  
  [

Détail des packs de goodies communs accompagnant les lots :

Casio NumWorks TI Xcas TI-Planète-Casio

• 1 stylo Casio au choix
• 1 clé USB Casio au choix :
  
  • clé USB Casio fx-CP400+E - 4,019 Go
  • clé USB Casio - 4,018 Go
• 1 batterie USB Casio
• 1 histoire intégrale imprimée du manga Casio Academy - ClassWiz Edition - Function Hero - épisode 1, 2 ou 3 au choix - 5 pages ci-dessous + page de fin secrète :
  
  • Episode 0 : Kaito (pour référence)
  • Episode 1 : Takuma
  • Episode 2 : Emi
  • Episode 3 : Azusa
  

• 1 manuel NumWorks au choix (N0100 ou N0110)
• 1 cahier d'activités NumWorks SNT 2nde
• 1 sac NumWorks au choix (N0100 versions 1.0-1.5, N0100 versions 1.6+, ou N0110)
• 1 cahier NumWorks
• 1 poster NumWorks au choix :
  
  • format A0 (118,9×84,1 cm²) : NumWorks N0100 - roulé
  • format A2 (42×59,4 cm²) :
    
    • NumWorks N0100 : Eduscol / Ministère de l'Education Nationale - roulé - brillant
    • NumWorks N0100 : Eduscol / Ministère de l'Education Nationale - roulé - mat
    • NumWorks N0100 : @Pims / @qabosse / @antalpilipili et ses collègues d'EPS - roulé
    • NumWorks N0100 : Xavier Andréani / TI-Planet - roulé - dédicacé
    • NumWorks N0110 : Comprendre le monde devient un jeu - plié
• 1 stylo NumWorks

• 1 stylo TI au choix
• 1 porte-documents TI
• 1 poster TI plié au choix :
  
  • format ANSI-D (55,9×86,4 cm²) : TI-73 Explorer
  • format A1 (59,4×84,1 cm²) : TI-89 Titanium
  • format 55,75×83,5 cm² : TI-Nspire CX, TI-Nspire CX CAS
• 1 clé USB TI au choix :
  
  • clé USB T3 France bleue - 2 Go de capacité nominale
  • clé USB TI-Primaire Plus - 4,01759 Go de capacité réelle
  • clé USB TI-Innovator Rover - 4,01813 Go de capacité réelle
  • clé USB TI-83 Premium CE avec lanière - 4,01811 Go de capacité réelle
  • clé USB TI-83 Premium CE avec chaînette - 4,01811 Go de capacité réelle
  • clé USB TI rouge - 1 Mo de capacité nominale (promotion TI-Primaire Plus défectueuse)
• 1 autocollant TI ou décalcomanie TI ou pochette CD TI ou lunettes TI au choix
• 1 cahier TI-83 Premium CE au choix

Aperçus de quelques cahiers d'activités TI-83 Premium CE Python au choix:

• Eyrolles : TI-83 Premium CE Edition Python - 2^nde Générale + Technique - Mathématiques extrait ou intégral au choix
• Eyrolles : TI-83 Premium CE Edition Python - Mathématiques + Physique-Chimie
• Eyrolles : TI-83 Premium CE Edition Python - SNT
• TI-83 Premium CE Edition Python - 2^nde Professionnelle - Mathématiques + Physique-Chimie
• Eyrolles : TI-83 Premium CE - BAC Pro - Mathématiques + Physique-Chimie
• Eyrolles : TI-83 Premium CE - 2^nde - ICN
• Eyrolles : TI-83 Premium CE - 2^nde + 1^ère - ICN

1 casquette Xcas ou tapis de souris Xcas ou autocollant Xcas

• 1 autocollant TI-Planet au choix
• 1 autocollant Planète Casio
• 1 compte premium TI-Planet

Le Léviathan, le serpent à pattes.

Au fin fond de la grotte du défi de Quetzalcóatl, ton excavatrice perce une dernière paroi et tombe sur le cratère d'un volcan. Tu as à peine le temps de sauter sur une corniche, qu'elle tombe déjà au fond du cratère et disparaît dans la lave en fusion.

Autour de ce cratère donc plusieurs corniches, reliées par des passerelles. Mais avec toutes ces émanations volcaniques, tu n'y vois pas à deux pas.

Heureusement, ton véhicule semble avoir eu le temps de télécharger un dernier script sur ta calculatrice.

Une étude de ce script montre que plusieurs dangers et péripéties te guettent sur ces corniches :

• le Léviathan, monstre mythologique ici incarné, niche sur une de ces corniches, et mieux vaut ne pas aller le déranger
• certaines corniches non peuplées ne sont pas sûres pour autant, dissimulant un puits qui te précipitera directement prendre ton dernier bain
• des chauves-souris géantes dorment sur certaines corniches ; elles ne sont pas mortelles en elles-mêmes, mais si tu les réveilles elles se saisiront de toi et t'emporteront sur une autre corniche sans te demander ton avis, et pas forcément sur une corniche sûre...
• une de ces corniches donne sur la porte de sortie, hélas verrouillée
• la clé de la porte est également présente sur une de ces corniches

Le script dispose de tout un système de détection, et t'indique ce qu'il y a à proximité de toi :

• le Léviathan est tellement nauséabond qu'il est détectable jusqu'à 2 passerelles de distance (corniches actuelle, voisines, ou voisines des voisines)
• la clé ainsi que les puits pour leur part ne sont détectables que jusqu'à 1 passerelle de distance (corniches actuelle ou voisines)
• les chauve-souris ainsi que la porte de sortie par contre ne sont détectables qu'une fois arrivé sur la corniche concernée

Une IA (Intelligence Artificielle) est également présente dans le script, mais visiblement ton véhicule n'a pas dû avoir le temps de la télécharger au complet, il n'y a pas grande intelligence dedans.

Ton but est donc d'améliorer l'IA fournie afin qu'elle ait les meilleures chances de te faire sortir sain·e et sauf·ve du cratère.

Nous te fournissons 3 scripts Python :

• polycal3.py, bibliothèque de compatibilité graphique gérant pas moins de 13 environnements Python graphiques sur calculatrices, officiels ou non
• web.py, définissant tout ce qui concerne le cratère du volcan et que nous te laissons le loisir de découvrir
• webtest.py, une IA parfaitement fonctionnelle mais totalement stupide, ne tenant compte d'aucun avertissement et ne réfléchissant pas, bref ne comprenant rien à la situation et décidant de ses actions au hasard

Les plateformes Python ici gérées sont les :

• Casio Graph 90+E / fx-CG50 comme tu viens de voir
• Casio Graph 35+E II
• HP Prime en mode CAS
• HP Prime avec appli Python intégrée (firmware alpha instable à ce jour, déconseillé)
• NumWorks (de préférence firmware Omega ou officiel)
• NumWorks + appli KhiCAS en mode Micropython (de préférence firmware Delta)
• NumWorks + appli KhiCAS en mode de compatibilité Python (de préférence firmware Delta)
• TI-Nspire CX II
• TI-Nspire + Ndless + Micropython
• TI-Nspire CX/CM + Ndless + Micropython
• TI-Nspire CX + Ndless + KhiCAS CX en mode Micropython
• TI-Nspire CX + Ndless + KhiCAS CX en mode de compatibilité Python

Show/Hide spoilerAfficher/Masquer le spoiler

Les TI-83 Premium CE Edition Python / TI-84 Plus CE-T Python Edition ne sont pas gérées cette fois-ci.

Le code est en théorie compatible, mais ici très conséquent.

Nous avons fait des efforts surhumains, pendant plusieurs jours, avons réussi à réduire la consommation de tas mémoire Python un peu en-dessous de 32K et donc à la faire tourner sur NumWorks avec l'appli Python officielle, l'appli KhiCAS tierce en mode Micropython, et même l'appli KhiCAS tierce dans le mode de compatibilité Python un peu plus gourmand.

Malheureusement les TI-83 Premium CE Edition Python et TI-84 Plus CE-T Python Edition n'offrent que 16K de mémoire de tas Python, et malgré plusieurs astuces tentées nous n'avons pas réussi ici à y faire tourner nos scripts sans erreur de mémoire.

Il te suffit donc d'améliorer la fonction ia(corniche, voisines, taille, capteurs, evenements).

Le tout démarre en appelant alors :

Code: Select all

from webtest import *
parcourir_selon(ia)

La fonction ia() sera ensuite appelée régulièrement, à chacun de tes déplacements, et te permettra d'en apprendre davantage sur la configuration de ce cratère :

• taille : le nombre de corniches présentes dans ce cratère (ne varie pas au cours d'une même partie), et qui seront numérotées de 0 à taille - 1
• corniche : numéro de la corniche sur laquelle tu te trouves actuellement
• capteurs : informations sur ce qui est détecté à partir de cette corniche :
  
  • capteurs & m_b indique la présence d'une chauve-souris sur la corniche actuelle
  • capteurs & (2 * m_b) indique en prime que la chauve-souris est prête à se saisir de toi
  • capteurs & m_d indique la présence de la porte de sortie sur la corniche actuelle
  • capteurs & m_k indique la présence de la clé sur les corniches voisines
  • capteurs & m_p alerte de la présence d'un ou plusieurs puits sur les corniches voisines
  • capteurs & m_l alerte de la présence du Léviathan sur les corniches voisines ou voisines des voisines
• evenements :
  
  • evenements & (2 * m_k) indique que tu as ramassé la clé de la sortie
  • evenements & m_a indique que tu disposes d'une flèche et es donc capable de tirer
  • evenements & (2 * m_l) indique que la flèche que tu as tirée a touché mortellement le Léviathan

La fonction ia() doit retourner une action à travers 2 valeurs :

• un numéro de corniche voisine
• l'action désirée :
  
  • 0 pour aller sur la corniche en question
  • 1 pour tirer ta flèche vers la corniche en question

Pour te permettre d'y voir clair, voici la fonction d'IA fournie par défaut commentée :

Code: Select all

def ia(corniche, voisines, taille, capteurs, evenements):
  # Nous sommes dans un cratere de volcan.
  # Il y a un nombre {taille} de corniches.
  # Les corniches sont numerotees de 0 a {taille - 1}.

  # Nous sommes sur la corniche numero {corniche}.
  if capteurs & m_b:
    # Une chauve-souris dort sur cette corniche. Elle se reveillera des que tu
    # seras parti.e au prochain tour !
    pass
  if capteurs & m_d:
    # Cette corniche donne sur la porte de sortie.
    pass
  if capteurs & m_p:
    # Une des corniches voisines dissimule un puits. Progresse prudemment !
    pass
  if capteurs & m_k:
    # Une des corniches voisines emet de la lumiere. La cle de la sortie doit
    # y etre !
    pass
  if capteurs & m_l:
    # Le Leviathan gronde. Il est a 2 pas ou moins d'ici. S'il n'est pas dans
    # une des corniches voisines, il est sur une voisine d'une voisine...
    pass
  if evenements & (2 * m_k):
    # Bravo, tu as trouve la cle de la porte de sortie !
    pass
  if evenements & m_a:
    # Tu peux tirer une fleche vers une des corniches voisines.
    pass
  if evenements & (2 * m_l):
    # Le Leviathan a ete touche mortellement, il ne pose plus de danger !
    pass
  if evenements & (2 * m_b):
    # Une chauve-souris t'as attrape.e, et t'emmene sur une autre corniche
    # sans te demander ton avis. Tu ne peux pas choisir ta destination !
    return None, 0

  # renvoie 2 valeurs :
  # * la corniche choisie parmi les voisines
  # * l'action relative desiree :
  #   - 0 pour aller sur cette corcniche
  #   - 1 pour tirer une fleche vers cette corcniche
  return voisines[randint(0, len(voisines) - 1)], 0

Ta calculatrice marquera ici une pause après chaque appel à cette fonction, afin de te laisser le temps de prendre connaissance de l'état affiché, attendant l'appui sur une touche pour demander à l'IA son coup suivant.
Dans le cas des calculatrices Casio, c'est obligatoirement la touche

AC/ON

qu'il te faut presser.

Aucune initiative n'est a priori interdite.

Tu es libre de définir et utiliser tout ce que tu veux (fonctions, variables globales, autres scripts...) mais ton code ne doit effectuer aucun accès en lecture ou écriture à des éléments de web.py autres que la fonction précédente à appeler, ni interférer avec leur fonctionnement.
Tu es également libre de modifier les scripts polycal3.py et web.py fournis si cela peut t'aider, mais note bien que ton script sera testé avec les scripts tels que téléchargés chez nous. Donc attention à ce que tout reste bien fonctionnel.

Note que l'IA fournie par défaut est ici parfaitement fonctionnelle, et arrive à gagner de temps en temps. Tu es parfaitement libre de ne rien coder et de participer avec notre IA aléatoire.

Une fois ton script prêt, il te suffira de nous l'envoyer par courriel à info@tiplanet.org , avec :

en objet : défi du Léviathan

une adresse courriel personnelle valide, si différente de l'adresse utilisée pour l'envoi de la participation

ton adresse postale complète avec nom et prénom(s)

si tu le souhaites, ton pseudonyme sur TI-Planet ou Planète Casio
(la liste des participants publiée en fin de concours utilisera les pseudonymes si fournis, et à défaut seulement les prénoms et initiales des noms)

si tu le souhaites, sans conséquence sur ta victoire ou ton choix de lot, les badges à afficher dans notre classement à côté de tes participations :

• l'équipe que tu soutiens : TI-Planet ou Planète Casio
• la guilde que tu soutiens : Casio, Hewlett Packard, Lexibook, NumWorks, Symbolibre ou Texas Instruments

un numéro de téléphone personnel valide
(utilisé uniquement dans ton intérêt en cas d'urgence - par exemple en cas de problème avec une participation ou un choix de lot et qu'il reste peu de temps pour participer/répondre)

Note que les participations seront évaluées :

• en faisant tourner les IA reçues sur un grand nombre de parties
• en regardant le nombre de fois où elles auront réussi à sortir du volcan sans dommages
• et en tenant compte du nombre de coups moyen qui aura été nécessaire dans ce cas

Ressources :

Casio
Graph HP
Prime Num
Works TI-Nspire
CX II TI-Nspire
Ndless

Scripts Python


Mises à jour :

• Système 3.50 pour Graph 90+E / fx-CG50 avec Windows / Mac
• Système 3.40 pour Graph 35+E II / fx-9750/9860GIII avec Windows

Emulation / simulation :

• Graph 90+E / fx-CG50 version 3.40 pour Windows / Mac
• Graph 35+E II version 3.30 pour Windows
  (période d'essai gratuite sans engagement de 90 jours, prolongeable gratuitement si besoin jusqu'au 31 décembre 2020)
• Graph 90+E version 3.50 (pour clé USB d'émulation officielle)
• Graph 35+E II version 3.40 (pour clé USB d'émulation officielle)

Transfert de données :

• tutoriel (Graph 90+E / Graph 35+E II / fx-CG50)

Scripts Python

Show/Hide spoilerAfficher/Masquer le spoiler

Aide à l'utilisation :

1. Transférer les 3 fichiers polycal3.hpprgm, web.hpprgm et webtest.hpprgm
2. Editer et fermer le programme polycal3
3. Editer et fermer le programme web
4. Editer et fermer le programme webtest
5. Aller dans la calculatrice CAS
6. Taper parcourir_selon(ia)
7. Taper une touche pour passer chaque action de l'IA

Emulation / simulation :

• logiciel HP Prime Virtual Calculator version 14425 pour Windows 64-bits / Windows 32-bits / Mac (gratuit)
• logiciel HP Prime Virtual Calculator version 14288 pour Linux 64-bits / Linux 32-bits (gratuit; attention - version bêta)
• installation appli HP Prime Lite/Free Android / iOS / Windows (gratuit)
• installation appli HP Prime Pro Android / iOS / Windows (19,99-24,99€)
  Attention - à date de publication, les applications Android ont été temporairement supprimées du Google Play Store. En attendant l'appli gratuite à installer manuellement est téléchargeable ci-dessous.
• téléchargement appli HP Prime Lite pour Android

Transfert de données et mises à jour :

• logiciel de connectivité version 14425 pour Windows 64-bits / Windows 32-bits / Mac
• tutoriel

Scripts avec simulateur + outil de transfert intégrés :

• chez Omega
• chez NumWorks

Mise à jour : https://workshop.numworks.com/devices

Applications additionnelles avec langage Python :

• logiciel Delta + application KhiCAS
• logiciel Omega + application KhiCAS

Emulation / simulation :

• logiciel NumWorks pour navigateur en ligne (gratuit)
• logiciel Omega pour navigateur en ligne (gratuit)
• logiciel NumWorks version 14.4.0 pour navigateur hors ligne (gratuit)
• logiciel Omega pour navigateur hors ligne (gratuit)
• application NumWorks pour Android / iOS (gratuite)
• application Omega pour Android
• logiciel Omega pour Nintendo 3DS

Transfert de données :

• tutoriel

Scripts Python


Mises à jour nécessaires :

• Système 5.2 pour TI-Nspire CX II CAS (également TI-Nspire CX II-T CAS / TI-Nspire CX II-C CAS)
• Système 5.2 pour TI-Nspire CX II-T
• Système 5.2 pour TI-Nspire CX II

Emulation / simulation + transfert de données :

• TI-Nspire CX CAS + TI-Nspire CX version 5.2 édition enseignant pour Windows / Mac (période d'essai gratuite sans engagement de 90 jours)
• TI-Nspire CX CAS version 5.2 édition élève pour Windows / Mac (période d'essai gratuite sans engagement de 30 jours)
• TI-Nspire CX version 5.2 édition élève pour Windows / Mac (période d'essai gratuite sans engagement de 30 jours)
• TiLP-II version 1.18 pour Windows / Mac / Linux (gratuit)

Emulation / simulation :

• Firebird pour Windows / Mac / Android / iOS

Scripts Python

Show/Hide spoilerAfficher/Masquer le spoiler

Aide à l'utilisation :

KhiCAS CX
mode
Micropython

KhiCAS CX
mode
compatibilité Python

Ajouts relatifs au Python :

• jailbreak Ndless
• KhiCAS CX
• interpréteur MicroPython
• éditeur NoteWriter
• éditeur pyWrite

Emulation / simulation :

• Firebird pour Windows / Mac / Android / iOS

Transfert de données :

• TI-Nspire Computer Link version 3.9 pour Windows / Mac (gratuit)
• tutoriel TI-Nspire Computer Link
• TI-Nspire CX CAS + TI-Nspire CX version 5.2 édition enseignant pour Windows / Mac (période d'essai gratuite sans engagement de 90 jours)
• TI-Nspire CX CAS version 5.2 édition élève pour Windows / Mac (période d'essai gratuite sans engagement de 30 jours)
• TI-Nspire CX version 5.2 édition élève pour Windows / Mac (période d'essai gratuite sans engagement de 30 jours)
• TiLP-II version 1.18 pour Windows / Mac / Linux (gratuit)

Liens :

• classement en ligne
• topic d'entraide

Référence : https://www.planet-casio.com/Fr/forums/ ... athan.html