Un démineur en python pour la NumWorks

[jules.py]

salut, super script juste par curiosité pourquoi cela ne marche pas sur omega

[critor]

demineur.py script de Arthur Jacquin, annoncé ici, Lien workshop

Le lien workshop semble ne plus marcher, erreur 404 :
https://workshop.numworks.com/python/ar ... n/demineur

Que se passe-t-il ?

Merci.

[cent20]

Changement de nom ?
Il est ici non ? https://workshop.numworks.com/python/ar ... inesweeper

[critor]

Merci.

Ben faut pas changer les noms, du moins avec le workshop officiel.
ça casse tous les liens déjà partagés.

C'est l'un de ses principaux défauts.

[Afyu]

Cet article est très intéressant !

J'ai passé un paquet d'heures à optimiser mes derniers scripts Python (des jeux pour la NumWorks, que l'on peut retrouver sur le site, dans les Jeux NumWorks justement) et j'ai découvert des choses intéressantes. Je n'ai pas utilisé de double chevron "<<" par contre.

Le problème du blanc semble avoir été résolu pour fill_rect mais pas encore pour draw_string, en tous cas. Le texte affiché avec le paramètre 'white' ou le triplet (255,255,255) n'est pas tout à fait blanc et est visible. Ça donne des caractères gris très clair, un peu fantomatiques. https://github.com/numworks/epsilon/issues/1643

Plus loin, on trouve

Code: Select all

if (v-42)%100 == 0: gps(x,y,0)
    else: gps(x,y,9)

. J'aurais plutôt écrit :

Code: Select all

gps(x,y, 0 if v%100 == 42 else 9)

à la place de ces deux lignes.

On peut même remplacer ça par :

Code: Select all

gps(x,y,9*(v%100 != 42))

le test d'inégalité renvoie un booléen qui est alors transformé en 0 ou en 1 lors de la multiplication.

[Dogm]

Au niveau performance vos codes sont équivalents ou ils apportent des gains ?

[Bisam]

On peut même remplacer ça par :

Code: Select all

gps(x,y,9*(v%100 != 42))

le test d'inégalité renvoie un booléen qui est alors transformé en 0 ou en 1 lors de la multiplication.

C'est vrai mais là, ça ressemble plus à du C, et on perd tout l'intérêt du Python, à savoir la lisibilité du code !

Quant aux performances, je suis à peu près persuadé que l'opérateur ternaire qu'est truc if test else machin est interprété exactement de la même façon que le "recast" de booléen en "integer".

[Afyu]

On peut même remplacer ça par :

Code: Select all

gps(x,y,9*(v%100 != 42))

le test d'inégalité renvoie un booléen qui est alors transformé en 0 ou en 1 lors de la multiplication.

C'est vrai mais là, ça ressemble plus à du C, et on perd tout l'intérêt du Python, à savoir la lisibilité du code !

Certes, mais la mémoire de la NumWorks n'est pas extraordinaire non plus, alors c'est un moyen d'optimiser (en raccourcissant) ses scripts pour pouvoir tous les mettre sur la calculatrice et partir en vacances avec.

Mais effectivement, ça nuit grandement à la lisibilité du code, et il peut être intéressant de garder une version pas optimisée mais lisible (et éventuellement commentée !) à disposition des curieux

[cent20]

Certes, mais la mémoire de la NumWorks n'est pas extraordinaire non plus, alors c'est un moyen d'optimiser (en raccourcissant) ses scripts pour pouvoir tous les mettre sur la calculatrice et partir en vacances avec.

Mais effectivement, ça nuit grandement à la lisibilité du code, et il peut être intéressant de garder une version pas optimisée mais lisible (et éventuellement commentée !) à disposition des curieux

De ce que j’ai compris de Critor - en espérant qu’il me pardonnera si j’ai compris de travers - ce n’est pas parce que le script est court qu’il utilise peu de place en mémoire de stockage.

Au début, je mettais : p = print pour gratter des octets, mais à l’exécution j’ai défini une variable de plus, donc mauvais deal...

Le vrai progrès ça sera le jour où les scripts seront stockés dans les 8mo et pas dans la RAM !

[Afyu]

Certes, mais la mémoire de la NumWorks n'est pas extraordinaire non plus, alors c'est un moyen d'optimiser (en raccourcissant) ses scripts pour pouvoir tous les mettre sur la calculatrice et partir en vacances avec.

Mais effectivement, ça nuit grandement à la lisibilité du code, et il peut être intéressant de garder une version pas optimisée mais lisible (et éventuellement commentée !) à disposition des curieux

De ce que j’ai compris de Critor - en espérant qu’il me pardonnera si j’ai compris de travers - ce n’est pas parce que le script est court qu’il utilise peu de place en mémoire de stockage.

Au début je mettais : p = print pour gratter des octets, mais à l’exécution j’ai défini une variable de plus, donc mauvais deal...

Le vrai progrès ça sera le jour où les scripts seront stockés dans les 8mo et pas dans la RAM !

Certes, mais tu ne les exécutes pas tous en même temps (enfin, j'espère ! ). Par contre, si tu pars en vacances sans ordi, et sans Internet, il faut que tu les mettes tous sur ta calculatrice en même temps, avant de partir.
Si j'ai bien compris, à l'exécution, le script est intégralement copié dans la RAM, donc plus le script est court et plus tu y gagnes. Mais si tu définis une variable supplémentaire, alors ça prend plus de place dans le stack et dans le heap (je ne me trompe pas ?). Dilemme !