Page 5 of 6

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 09:49
by cent20
Arthur Jacquin wrote:Je vous laisse tester tout ça : https://workshop.numworks.com/python/ar ... n/demineur


0. Le chargement du champs de mine caché est un peu long, mais c'est du au codage case par case.
1. l'écran scintille au premier clic, j'ai l'impression qu'il révèle le placement des mines, il faudrait le filmer à 120fps pour voir ...
2. Le texte est mieux centré que sur le mien
3. Très sympa la possibilité de cliquer sur une case "chiffree déjà découverte après placement des drapeaux.

Je viens d'obtenir un crash. Le jeu c'est bloqué. Ça ressemble à une saturation de la mémoire. Après c'est peut-être un crash d'Omega et pas du jeu. On ne saura jamais ... :D

2ème partie : J'ai découvert toutes les cases sauf les mines et il ne me dit pas que j'ai gagné ! J'en déduit que tu exiges le placement des mines. Est-ce le cas du démineur original ?

En tout cas c'est bien jolie, tu es prêt pour intégrer la team amateur du défi Développe​r des projets avec Kandinsky sur PC :) Et je pense que tu aurais pu faire les défis python en octobre dernier plutôt que faire que des maths ;)

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 10:03
by Arthur Jacquin
cent20 wrote:
Arthur Jacquin wrote:J'ai rempli mon cahier des charges (et la mémoire de la calculatrice :)),

As tu eut des messages d'erreur avec la mémoire ou c'est juste une blague pour relancer sur la limite des 16ko ?

Non c'est juste pour dire que mon script a encore grossi mais aucun message d'erreur sur Omega. Omega made what epsilon't.
cent20 wrote:J'ai imaginé hier soir un système où l'on stocke les bombes dans les couleurs des pixels, un tel système remplacerait la matrice 15*10 ou 17*10 dans ton cas et occuperait inévitablement moins de mémoire.

Si un pixel de la grille est par exemple codé en RGB en (192,192,192) je me demande si on verrait la différence avec (192,193,192) par exemple, et comme il existe une instruction get_pixel(x,y) on peut interroger les couleurs des différents pixels...

Hum ... Je suis pas encore dans la phase intensive d'optimisation mais c'est pas par là que je commencerai.
cent20 wrote:1. l'écran scintille au premier clic, j'ai l'impression qu'il révèle le placement des mines, il faudrait le filmer à 120fps pour voir ...

Merci. C'est réglé.
cent20 wrote:3. Très sympa la possibilité de cliquer sur une case "chiffree déjà découverte après placement des drapeaux.

Très pratique effectivement, mais je me demande vraiment si ce n'est tricher. La fonction ne s'active que si toutes et uniquement les bombes des cases mitoyennes sont couvertes de drapeau, donc si on a mal déminé ça ne s'affiche pas, et on sait qu'on s'est trompé sans perdre ... Je réfléchis à comment punir l'utilisateur.
cent20 wrote:Je viens d'obtenir un crash. Le jeu c'est bloqué. Ça ressemble à une saturation de la mémoire. Après c'est peut-être un crash d'Omega et pas du jeu. On ne saura jamais ... :D

Il y a quelquefois des blocages. Je ne pense pas que cela provienne d'un problème de mémoire, je pense plutôt que c'est l'appui sur un bouton lors de l’exécution d'une commande qui ne le supporte pas, car le message d'erreur est : "Keyboard Interrupt". Je ne sais pas comment résoudre ce problème mais je pense qu'il est mineur, les blocages étant relativement rares.
cent20 wrote:2ème partie : J'ai découvert toutes les cases sauf les mines et il ne me dit pas que j'ai gagné ! J'en déduit que tu exiges le placement des mines. Est-ce le cas du démineur original ?

Vous avez probablement téléchargé le script lors d'un des tests : il y a désormais la possibilité d'enlever les drapeaux placés ! :D Le problème de victoire non détectée est réglé.
cent20 wrote:tu es prêt pour intégrer la team amateur du défi Développe​r des projets avec Kandinsky sur PC :)

Merci bien, mais je réfléchis à un snake actuellement. J'aurais peut-être pu vous aider si je n'étais pas censé faire une introduction de cours pour demain. :whistle: :'D

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 10:15
by cent20
Arthur Jacquin wrote:Hum ... Je suis pas encore dans la phase intensive d'optimisation mais c'est pas par là que je commencerai.


Et pourtant ... Comme l'ont démontré Bisam et Critor, l'utilisation des listes consomme beaucoup de mémoire. Même chose pour le .append()

Arthur Jacquin wrote:Très pratique effectivement, mais je me demande vraiment si ce n'est tricher. La fonction ne s'active que si toutes et uniquement les bombes des cases mitoyennes sont couvertes de drapeau, donc si on a mal déminé ça ne s'affiche pas, et on sait qu'on s'est trompé sans perdre ... Je réfléchis à comment punir l'utilisateur.


Bien vu ! Super-pratique pour tricher (...)

Arthur Jacquin wrote:Il y a quelquefois des blocages. Je ne pense pas que cela provienne d'un problème de mémoire, je pense plutôt que c'est l'appui sur un bouton lors de l’exécution d'une commande qui ne le supporte pas, car le message d'erreur est : "Keyboard Interrupt". Je ne sais pas comment résoudre ce problème mais je pense qu'il est mineur, les blocages étant relativement rares.


C'est pour cette raison que je place les drapeau avec [CLEAR] et pas [backspace].
Je suis convaincu que parfois, l'OS de la Numworks intercepte le clic sur la touche [backspace] et quitte la boucle du programme ("Keyboard Interrupt"). Au départ j'avais aussi programmé avec [OK] et [backspace] et j'avais en effet ce genre de crash.
Depuis [backspace] est réservé dans mon script pour interrompre le script. D'ailleurs je me suis retrouvé dans une boucle infini et impossible de quitter ton programme, aucune touche ne semble dédiée à ça.
rmais la possibilité d'enlever les drapeaux placés ! :D Le problème de victoire non détectée est réglé.

Arthur Jacquin wrote:J'aurais peut-être pu vous aider si je n'étais pas censé faire une introduction de cours pour demain. :whistle: :'D


Il a le droit de te faire travailler gratuitement comme ça ton prof ?

Ah on me dit dans l'oreillette que je suis ton prof et que ce qui est marqué dans le cahier de texte est en effet obligatoire... :troll:

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 10:25
by Arthur Jacquin
cent20 wrote:Au départ j'avais aussi programmé avec [OK] et [backspace] et j'avais en effet ce genre de crash.


Je vais y réfléchir.

cent20 wrote:D'ailleurs je me suis retrouvé dans une boucle infini et impossible de quitter ton programme, aucune touche ne semble dédiée à ça.


Il faut spammer Accueil et Flèche retour, mais aucune boucle infinie ça c'est sûr.

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 11:06
by Dogm
cent20 wrote:
Arthur Jacquin wrote:J'ai rempli mon cahier des charges (et la mémoire de la calculatrice :)),


As tu eut des messages d'erreur avec la mémoire ou c'est juste une blague pour relancer sur la limite des 16ko ?

J'ai imaginé hier soir un système où l'on stocke les bombes dans les couleurs des pixels, un tel système remplacerait la matrice 15*10 ou 17*10 dans ton cas et occuperait inévitablement moins de mémoire.

Si un pixel de la grille est par exemple codé en RGB en (192,192,192) je me demande si on verrait la différence avec (192,193,192) par exemple, et comme il existe une instruction get_pixel(x,y) on peut interroger les couleurs des différents pixels...

Je ne sais plus où j'ai lu cette astuce (surement sur ce site) et initialement je l'ai imaginé pour savoir si une case à un drapeau ou non, il suffit de tester la présence d'un pixel rouge (dans ton cas) et d'un pixel gris (dans le mien, à cause du "!" en gris).

Reste à savoir si interroger la couleur d'un pixel est plus long que parcourir une matrice, et je dirais intuitivement que c'est bien le cas. En tout cas je ne vais pas intégrer ceci (sauf peut être pour le drapeau), c'est juste une expérience de pensée qui permet de libérer plus de 6ko dans mon cas près de 7ko dans ton cas.


Bonne idée mais
get_pixel
est buggé :(

Créer un rectangle entièrement blanc et utilise
get_pixel
, le résultat qu'elle retourne n'est pas précis.

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 15:31
by Adriweb
Est-ce que tu peux faire une issue github à ce sujet ? (Si tu as toujours le bug dans la derniere version du repo (master))

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 17:50
by parisse
cent20 wrote:Et pourtant ... Comme l'ont démontré Bisam et Critor, l'utilisation des listes consomme beaucoup de mémoire. Même chose pour le .append()

Ca me parait un peu etonnant que append consomme beaucoup de memoire, car la liste est modifiee en place. Evidemment quand on atteint la capacite de la liste, il faut augmenter la taille de la liste et sans indication particuliere, l'implementation consistera par exemple a creer une copie de la liste dont la capacite a ete multipliee par deux. La libstdc++ permet de reserver (un majorant de) la taille de la liste pour eviter de devoir reallouer la liste (ce qui peut etre trop couteux en temps d'execution, en particulier si on manipule des donnees de taille plus grande que les tailles caracteristiques des caches memoires) et aussi pour controler la capacite finale de la liste. En Python je n'ai pas l'impression qu'il existe de commande pour ca, mais je pense qu'on doit aboutir a un resultat equivalent en creant une liste de 0 de la taille de la capacite voulue puis en faisant clear sur la liste.

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 18:46
by redgl0w
Adriweb wrote:Est-ce que tu peux faire une issue github à ce sujet ? (Si tu as toujours le bug dans la derniere version du repo (master))


J'en ai déjà ouvert un, et on m'a expliqué qu'en faite, kandinsky (pas le module python mais le composant gérant l'affichage) utilisait pour les couleurs du RGB565 codé non pas sur 24 bits mais 16, ce qui créé des incohérences...
Les fonctions pythons du module kandinsky, hormis color() utilisant les couleurs RGB de kandinsky se plient à la règle aussi, et ne sont donc que des conversions de rgb codé en 16 bits vers 24, ou l'inverse...
Cf. l'issue : https://github.com/numworks/epsilon/issues/1363

Re: Un démineur en python pour la NumWorks

Unread postPosted: 08 Mar 2020, 18:47
by redgl0w
Arthur Jacquin wrote:
cent20 wrote:D'ailleurs je me suis retrouvé dans une boucle infini et impossible de quitter ton programme, aucune touche ne semble dédiée à ça.


Il faut spammer Accueil et Flèche retour, mais aucune boucle infinie ça c'est sûr.



Cet issue est normalement corrigé sur epsilon master

Re: Un démineur en python pour la NumWorks

Unread postPosted: 31 Mar 2020, 21:37
by cent20
Archivage de mon article originel (avant la sortie de la version 13.2.0) d'Epsilon.

Le contenu de ce message n'est plus d'actualité, NumWorks ayant décidé de résoudre ce qu'à titre personnel je considérais être le principal problème de cette calculatrice.


LA GESTION DE LA MÉMOIRE PYTHON SUR LA NUMWORKS, UN ÉPINEUX PROBLÈME

La mémoire, c’est comme les amis ; elle vous laisse souvent tomber au moment où on a le plus besoin.


Ce proverbe espagnol trouve son sens ici.

En plein milieu du développement, et alors que mon script ne faisait que 2.6 ko l’émulateur NumWorks associé au workshop refusa d’exécuter mon script.

MemoryError : memory allocation failed , allocating XXX bytes.


Si je savais pertinemment que la fin du développement ne pourrait se faire que sur la calculatrice elle-même, car le workshop ne fonctionne pas sur la version beta d’epsilon, le logiciel qui fait tourner la numworks mais j’ai été bloqué bien avant d’arriver à la problématique des getkey.

La calculatrice dispose de 16ko réservé à l’exécution des scripts, c’est à dire la quantité de mémoire fixé au strict minimum recommandé par les développeurs de MicroPython :

Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM


Pour installer windows 10, la configuration requise par Microsoft est :

Processeur :Processeur de 1 GHz ou plus rapide
RAM : 1 gigaoctet (Go) pour système 32 bits ou 2 Go pour système 64 bits
16 Go pour système 32 bits ou 32 Go pour système 64 bits


Tout utilisateur de Windows 10 sait très bien que ces chiffres ne suffisent pas, et qu’un tel système sera lent, peu efficace, son utilisation ne sera pas agréable.

On peut légitimement penser qu’il en est de même avec MicroPython. 16ko suffisent d’après la documentation, mais si s’était le cas pourquoi les MicroPython boards datées de 2016 proposent-elles en moyenne une mémoire utile de 85 ko ?

Pourquoi les autres fabricants de calculatrice graphique ont décidé de proposer plus de mémoire pour l’exécution des scripts ?

Un testeur de la calculatrice Graph 35+E II, entrée de gamme chez Casio équivalent à celui de la numworks, écrivait en mai 2019 dans l’article de présentation de cette calculatrice :

Cela n’est pas surprenant, car l’ancien tas faisait 48 ko et c’est assez peu pour un interpréteur Python. Casio a certainement commencé à exploiter la deuxième moitié de RAM à sa disposition pour satisfaire les besoins de Python. Les scripts de Critor révèlent que le nouveau tas fait environ 90 ko, quasiment deux fois plus que l’ancien.


Ainsi, chez Casio le tas python est passé de 48ko à 90ko, tandis que sur NumWorks on rêverait d’avoir 48ko, mais 32ko pourrait être un bon début, il suffit pour cela d’intégrer le Pull Requestde Lionel Debroux sur GitHub.

Paradoxalement, alors que la NumWorks est l’une des calculatrice la plus rapide lors de l’exécution des scripts Python, et que pour un prix d’achat de 79€ elle n’a clairement aucune concurrence, elle refuse d’exécuter des scripts python de 3koou 4ko sans que l’on ne comprenne vraiment la raison, si ce n’est une affectation insuffisante de mémoire pour l’exécution des scripts python.

Et pour reprendre l’intervention de Lionel Debroux sur la discussion associée au topic du site tiplanet.org : Script qui refuse de s’exécuter sur la Numworks N0100

C’est quand même inquiétant de ne pas pouvoir construire des programmes non triviaux sur beaucoup de modèles de calculatrices gérant Python...
Ce n’est pas comme ça qu’on va rendre populaire l’algorithmique et donner le goût de la programmation à certains élèves qui auraient pu être intéressés.

Ainsi, comme vous l’avez compris, ce démineur ne tournera pas* avec le logiciel Epsilon de la NumWorks, ni sur la version 12 actuelle, ni sur la prochaine version 13.0.0 dont la sortie prochaine est annoncée.

Et pourtant, le développement de ce démineur est achevé, et il marche !

Image

Le contenu de ce message n'est plus d'actualité, NumWorks ayant décidé de résoudre ce qu'à titre personnel je considérais être le principal problème de cette calculatrice.


Résumons en un mot :

Image

Merci NumWorks d'avoir enfin décidé de résoudre ce problème.


Promis je ne vous reparle plus du stack / heap avant au moins 1 an ! :troll: