A jouer aux reines avec une calculette de presque 40 ans !
Modérateur : Politburo
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
A jouer aux reines avec une calculette de presque 40 ans !
Bon, suite à un post paru sur le Forum MoHPc, donnant la référence d'un article de L'Ordinateur de Poche n°7 -p49 où une TI-58C est utilisée pour tenter de résoudre le problème de placer huit reines sur un échiquier sans qu'elles se crêpent le chinon, j'ai passé hier soir une excellente soirée.
Sans changer l'algorithme, mais tentant d'en optimiser la vitesse, je me suis mis à modifier le programme d'Alain DAIX.
Bien que n'ayant pas réussi à accélérer significativement le déroulement du calcul (gain d'environ 23s sur 3 min), je suis parvenu à une version entièrement paramétrée et surtout bien plus courte.
Je donne ci-dessous l'organigramme et le listing sommairement commenté (en anglais pour faciliter l'exportation à l'international) de ce petit bijou d'astuces. J'y utilise pour la première fois certaines instructions dont notamment tout un flot d'adressages indirects et quelque instruction de boucle avec saut inversé (INV DSZ x NN ) et d'autres étendues au delà de la limite prévue des registres 0 à 9. Il faut un peu éditer le code avec Del et Ins lors de la saisie (et pas uniquement pour corriger les faux-rebonds des touches ! ).
L'utilisation globale du code diffère un peu de l'original. On saisi la taille d de l'échiquier; Par exemple lancer par 4 A pour un demi-échiquier de taille 4x4 où seront placé 4 reines qui si elles restent sagement à leur place ne se feront pas la guerre.
Par contre l'usage des registres et l'algorithme est identique et une bonne partie des labels aussi. Le registre R00 sert d'indice de recherche. par contre, j'ai étendu la possibilité à résoudre des échiquiers plus grands (même si ce n'est pas très utile car très lent). De ce fait ma princesse peut mémoriser la position de 17 reines (registres R01 à R17 inclus) pour un échiquier maximal de 17x17 cases. Les registres R18 et R19 servent respectivement d'indice secondaire et à donner la taille de l'échiquier.
Ma princesse à mémoire continue trouve les deux solutions 2413 et 3142 en respectivement 1'08" et 1'45". Puis indique qu'il n'en existe plus d'autre au bout de 2'44" en s'arrêtant sur un affichage clignotant. C'est bien, mais les temps augmentent exponentiellement avec la taille de l'échiquier.
Ce matin, j'ai lancé quelque détermination pour un échiquier 8x8, la première solution est apparue en moins d'une heure-trente; mais trop occupé par ailleurs je n'ai pas arrêté le chronomètre à temps. Je suis un peu déçu, je voulais savoir si mon code met moins de temps de la code original.
En tout cas ce qui est dommage est que les ressources de la TI-58C/59 sont bien mal utilisées; 86 octets et moins de vingt registres.
Je suis donc à la recherche d'autres algorithmes, plus rapides et plus efficaces, qui exploiteront mieux le potentiel extraordinaire de ma petit fée boutonneuse.
Sans changer l'algorithme, mais tentant d'en optimiser la vitesse, je me suis mis à modifier le programme d'Alain DAIX.
Bien que n'ayant pas réussi à accélérer significativement le déroulement du calcul (gain d'environ 23s sur 3 min), je suis parvenu à une version entièrement paramétrée et surtout bien plus courte.
Je donne ci-dessous l'organigramme et le listing sommairement commenté (en anglais pour faciliter l'exportation à l'international) de ce petit bijou d'astuces. J'y utilise pour la première fois certaines instructions dont notamment tout un flot d'adressages indirects et quelque instruction de boucle avec saut inversé (INV DSZ x NN ) et d'autres étendues au delà de la limite prévue des registres 0 à 9. Il faut un peu éditer le code avec Del et Ins lors de la saisie (et pas uniquement pour corriger les faux-rebonds des touches ! ).
L'utilisation globale du code diffère un peu de l'original. On saisi la taille d de l'échiquier; Par exemple lancer par 4 A pour un demi-échiquier de taille 4x4 où seront placé 4 reines qui si elles restent sagement à leur place ne se feront pas la guerre.
Par contre l'usage des registres et l'algorithme est identique et une bonne partie des labels aussi. Le registre R00 sert d'indice de recherche. par contre, j'ai étendu la possibilité à résoudre des échiquiers plus grands (même si ce n'est pas très utile car très lent). De ce fait ma princesse peut mémoriser la position de 17 reines (registres R01 à R17 inclus) pour un échiquier maximal de 17x17 cases. Les registres R18 et R19 servent respectivement d'indice secondaire et à donner la taille de l'échiquier.
Ma princesse à mémoire continue trouve les deux solutions 2413 et 3142 en respectivement 1'08" et 1'45". Puis indique qu'il n'en existe plus d'autre au bout de 2'44" en s'arrêtant sur un affichage clignotant. C'est bien, mais les temps augmentent exponentiellement avec la taille de l'échiquier.
Ce matin, j'ai lancé quelque détermination pour un échiquier 8x8, la première solution est apparue en moins d'une heure-trente; mais trop occupé par ailleurs je n'ai pas arrêté le chronomètre à temps. Je suis un peu déçu, je voulais savoir si mon code met moins de temps de la code original.
En tout cas ce qui est dommage est que les ressources de la TI-58C/59 sont bien mal utilisées; 86 octets et moins de vingt registres.
Je suis donc à la recherche d'autres algorithmes, plus rapides et plus efficaces, qui exploiteront mieux le potentiel extraordinaire de ma petit fée boutonneuse.
Modifié en dernier par C.Ret le 23 mai 2022 18:57, modifié 2 fois.
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
- Ythunder
- Fonctionne à 9600 bauds
- Messages : 4562
- Enregistré le : 09 août 2008 17:46
- Localisation : 03
Re: A jouer aux reines sur une jeunette de presque 40 ans !
Euh... 23 secondes sur 3 minutes, perso je trouve ça énorme comme gain.
Et ça veut dire que le travail d'optimisation n'est pas vain du tout.
Quand je lis ça "oui des passionnées qui modifie des machines pour en faire des moutons a 5 pattes qui n'ont plus rien a voir avec la machine d'origine afin de faire la video choc sur youtube..."
Ca me fait rire. Perso, je n'ai ni chaine youtube sur les machines et je n'ai aucun mouton à 5 pattes qui n'a pàlus rien a voir avec des machines d'origine. Mais à qui s'adressait on ?
Ca me fait rire. Perso, je n'ai ni chaine youtube sur les machines et je n'ai aucun mouton à 5 pattes qui n'a pàlus rien a voir avec des machines d'origine. Mais à qui s'adressait on ?
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Re: A jouer aux reines sur une jeunette de presque 40 ans !
Oui, peut-être…
… mais hier soir, il était bien tard et je n'ai pas eut les idées encore assez claires pour démêler cela correctement.
Le problème est que je ne suis pas sûr de ma comparaison. En effet, même si j'ai gardé le principe fondamental de l'algorithme, mon optimisation a changé le sens de parcours de l'échiquier. Et comme les solutions ne sortent pas de façon régulière, je ne suis pas sûr de la validité de ma comparaison.
De plus, cette dernière version est un perfectionnement d'une version scannant dans un autre sens que le code original et aussi différent de la version actuelle. Sur le moment, la version actuelle, bien que réalisant un test de moins et combinant deux boucles en une seule - ce qui par rapport à la version concourante ne peut être qu'une amélioration - m'a parue bien plus lente.
Cela me paraissait étrange et je suis allé me couché. La nuit porte conseil. Ce n'est que ce matin, après avoir préparé mon post, que j'ai compris que ce paradoxe provient bel et bien de l'ordre différent des solutions trouvées.
Et comme aucune des trois versions dont je dispose n'effectue la recherche exactement dans les mêmes sens; je suis bien ennuyé pour évaluer rigoureusement les performances de tout cela ...
Par contre, j'ai bien avancé dans la documentation et la recherche d'algorithmes de résolution, et ce code est bel et bien basé sur le principe de recherche exhaustive par rétropropagation. C'est l'un des algorithmes qui parait le plus adapté à ce type de problème et effectivement il ne nécessite pas énormément de ressource (d'où le nombre faible de registres utilisés). Il garanti de trouver toutes les solutions qu'il cherche systématiquement.
Une alternative serai d'utiliser un algorithme glouton qui fonctionne par "réparations". Dans ce type d'algorithme la mémoire (donc le nombre de registres disponibles) peut permettre de réduire considérablement les calculs (à condition d'avoir trouvé le moyen de coder l'information afin de limiter les changements à chaque itération) conservant les invariants locaux. L'inconvénient est que l'on est sûr de ne pas être exhaustif, ni risquer de trouver deux fois une même solution.
Par ailleurs, l'échiquier 8x8 fait 64 cases, et contrairement à une Ti-59, une Ti58c n'a pas autant de registres disponibles; ce qui va limiter considérable les "pré-calculs" et autres "redondances".
… mais hier soir, il était bien tard et je n'ai pas eut les idées encore assez claires pour démêler cela correctement.
Le problème est que je ne suis pas sûr de ma comparaison. En effet, même si j'ai gardé le principe fondamental de l'algorithme, mon optimisation a changé le sens de parcours de l'échiquier. Et comme les solutions ne sortent pas de façon régulière, je ne suis pas sûr de la validité de ma comparaison.
De plus, cette dernière version est un perfectionnement d'une version scannant dans un autre sens que le code original et aussi différent de la version actuelle. Sur le moment, la version actuelle, bien que réalisant un test de moins et combinant deux boucles en une seule - ce qui par rapport à la version concourante ne peut être qu'une amélioration - m'a parue bien plus lente.
Cela me paraissait étrange et je suis allé me couché. La nuit porte conseil. Ce n'est que ce matin, après avoir préparé mon post, que j'ai compris que ce paradoxe provient bel et bien de l'ordre différent des solutions trouvées.
Et comme aucune des trois versions dont je dispose n'effectue la recherche exactement dans les mêmes sens; je suis bien ennuyé pour évaluer rigoureusement les performances de tout cela ...
Par contre, j'ai bien avancé dans la documentation et la recherche d'algorithmes de résolution, et ce code est bel et bien basé sur le principe de recherche exhaustive par rétropropagation. C'est l'un des algorithmes qui parait le plus adapté à ce type de problème et effectivement il ne nécessite pas énormément de ressource (d'où le nombre faible de registres utilisés). Il garanti de trouver toutes les solutions qu'il cherche systématiquement.
Une alternative serai d'utiliser un algorithme glouton qui fonctionne par "réparations". Dans ce type d'algorithme la mémoire (donc le nombre de registres disponibles) peut permettre de réduire considérablement les calculs (à condition d'avoir trouvé le moyen de coder l'information afin de limiter les changements à chaque itération) conservant les invariants locaux. L'inconvénient est que l'on est sûr de ne pas être exhaustif, ni risquer de trouver deux fois une même solution.
Par ailleurs, l'échiquier 8x8 fait 64 cases, et contrairement à une Ti-59, une Ti58c n'a pas autant de registres disponibles; ce qui va limiter considérable les "pré-calculs" et autres "redondances".
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Aurais-je une Ti-58C particulièrement lente ??
Voilà, pour progresser à la mise au point de mon programme de résolution du problème des N-Reines, je me suis mis à profiler mon code actuel afin de voir quel est l'importance des différentes parties et donc trouver éventuellement quelques endroits où grapiller encore un peu quelques cycles.
Concernant la recherche d'algorithme plus efficace, je laisse un peu tomber pour le moment. Celui utilisé est partout présenté comme le plus abouti et le plus performant. Les accélérations proposées par certains algorithmes tirent partie de certaines fonctionnalités de langages de programmation plus évoluées. Je citerai rapidement l'utilisation des SET en Python et de l'arithmétique binaires de certains pockets BASIC.
Mais avec une TI-58/59, ces accélérations ne me sont d'aucune utilité, au contraire pour simuler ces fonctions, il me faudrait bien plus de pas et de tests que n'en comporte mon code qui justement exploite bien l'adressage indirect et minimise le nombre total des tests profitant pleinement des instructions de boucles. Avec, cerise sur le gateau, un registre de test t qui reste tout le long du programme à zéro.
Par contre, je bataille à obtenir les temps indiqués par Alain DAIX dans l'article de OP n°7. Bien qu'ayant réduit considérablement la taille du programme tout en utilisant rationnellement les instruction de boucle DSZ (ou DSnZ d'ailleurs) j'obtiens toujours des temps de détermination un peu plus long que ceux de la machine d'Alain.
J'ai d'ailleurs trouvé un moyen de mieux chronométrer ma Ti58C. Comme elle ne peux pas sonner l'affichage d'une solution, j'utilise un petit poste récepteur calé sur 1355 kHz et collé à la Ti. Pendant que la Ti58C tricote le code son écran est éteint et je n'entend dans le petit poste de radio qu'un grésillement (le bruit bruit blanc entre deux stations). Par contre, un fort sifflement, très aigu se fait entendre lors de l'affichage d'une solution, ce qui me permet d'arrêter le chronomètre dans la seconde.
Alors, je me suis demandé si en utilisant exactement le code d'Alain, j'obtenais moi aussi 52 min pour la première solution du problème à 8-Reines.
Et non, avec ma machine, j'obtiens la première solution au bout de 1h27' au lieu des 52 min annoncées !
Mince, j'ai une Ti-58C lente ??
Du coup, la performance du code ci-dessus qui affiche la première solution au bout de 1h01' est effectivement une amélioration ! Je commençais à désespérer.
Bon, il y a moyen d'encore accélérer mon code. Noter qu'à l'instruction 051, le GTO = est répété 26618 fois (pour une détermination des 92 solutions). C'est de loin le saut qui est répété le plus souvent. Le remplacer par un très rapide RST va certainement bien diminuer le temps d'exécution.
Il m'a donc fallu tout recomposer en reprenant exactement les différentes parties du code précèdent mais en les réorganisant dans un ordre qui limite considérablement la longueur des sauts...
L'utilisation d'un RST au lieu du label Lbl = permet une bonne accélération; j'obtiens maintenant la première solution après seulement 47 min (au lieu 1h 27 min), soit une diminution de 46% c'est énorme !!
Si j'avais une Ti58 aussi véloce que celle qu'avait Alain DAIX, la solution apparaitrait au bout de 32 min seulement
Pendant que la TI-58C chercher à placer les huit reins sur l'échiquier, je me suis amusé à tester mon SHARP PC-1211 sur le même problème en utilisant exactement le même algorithme et en cherchant aussi à limiter les "sauts".
Mon SHARP PC-1211 , qui n'est pas une machine rapide, affiche la première solution des 8-reines en environ 38 min avec le code suivant:
La partie qui teste si deux reines sont en conflit est volontairement aux lignes 1: et 2: afin de limiter au maximum le temps cumulé des très nombreux GOTO 1
Les ligne 2: et 3: sont en fait la partie sous le label Lbl E qui décrémente position testée et indice de colonne.
La ligne 7: est un peu loin, mais comme elle est longue, la mettre au début du programme ralenti tous les sauts. Il y a peut-être moyen d'optimiser un peu en trouvant un meilleurs compromis. Mais c'est difficile, il ne faut pas oublier qu'il n'y aura au total que 2057 sauts vers la ligne 7: alors que les lignes 2: ou 3: compte pour respectivement 15720 et 1965. Là où les lignes 1: et 2: correspondent à 42338 passages.
Voilà le type de considérations qui permettent de gagner quelques heures, car avec son meilleurs rendement, je peux espérer avoir le listing des 92 solutions en moins de 10 heures même sur ma Ti58C qui prend son temps...
Juste que ce serai bien si j'avais une PC-100...
... trop fainéant pour noter 92 solutions
Concernant la recherche d'algorithme plus efficace, je laisse un peu tomber pour le moment. Celui utilisé est partout présenté comme le plus abouti et le plus performant. Les accélérations proposées par certains algorithmes tirent partie de certaines fonctionnalités de langages de programmation plus évoluées. Je citerai rapidement l'utilisation des SET en Python et de l'arithmétique binaires de certains pockets BASIC.
Mais avec une TI-58/59, ces accélérations ne me sont d'aucune utilité, au contraire pour simuler ces fonctions, il me faudrait bien plus de pas et de tests que n'en comporte mon code qui justement exploite bien l'adressage indirect et minimise le nombre total des tests profitant pleinement des instructions de boucles. Avec, cerise sur le gateau, un registre de test t qui reste tout le long du programme à zéro.
Par contre, je bataille à obtenir les temps indiqués par Alain DAIX dans l'article de OP n°7. Bien qu'ayant réduit considérablement la taille du programme tout en utilisant rationnellement les instruction de boucle DSZ (ou DSnZ d'ailleurs) j'obtiens toujours des temps de détermination un peu plus long que ceux de la machine d'Alain.
J'ai d'ailleurs trouvé un moyen de mieux chronométrer ma Ti58C. Comme elle ne peux pas sonner l'affichage d'une solution, j'utilise un petit poste récepteur calé sur 1355 kHz et collé à la Ti. Pendant que la Ti58C tricote le code son écran est éteint et je n'entend dans le petit poste de radio qu'un grésillement (le bruit bruit blanc entre deux stations). Par contre, un fort sifflement, très aigu se fait entendre lors de l'affichage d'une solution, ce qui me permet d'arrêter le chronomètre dans la seconde.
Alors, je me suis demandé si en utilisant exactement le code d'Alain, j'obtenais moi aussi 52 min pour la première solution du problème à 8-Reines.
Et non, avec ma machine, j'obtiens la première solution au bout de 1h27' au lieu des 52 min annoncées !
Mince, j'ai une Ti-58C lente ??
Du coup, la performance du code ci-dessus qui affiche la première solution au bout de 1h01' est effectivement une amélioration ! Je commençais à désespérer.
Bon, il y a moyen d'encore accélérer mon code. Noter qu'à l'instruction 051, le GTO = est répété 26618 fois (pour une détermination des 92 solutions). C'est de loin le saut qui est répété le plus souvent. Le remplacer par un très rapide RST va certainement bien diminuer le temps d'exécution.
Il m'a donc fallu tout recomposer en reprenant exactement les différentes parties du code précèdent mais en les réorganisant dans un ordre qui limite considérablement la longueur des sauts...
L'utilisation d'un RST au lieu du label Lbl = permet une bonne accélération; j'obtiens maintenant la première solution après seulement 47 min (au lieu 1h 27 min), soit une diminution de 46% c'est énorme !!
Si j'avais une Ti58 aussi véloce que celle qu'avait Alain DAIX, la solution apparaitrait au bout de 32 min seulement
Pendant que la TI-58C chercher à placer les huit reins sur l'échiquier, je me suis amusé à tester mon SHARP PC-1211 sur le même problème en utilisant exactement le même algorithme et en cherchant aussi à limiter les "sauts".
Mon SHARP PC-1211 , qui n'est pas une machine rapide, affiche la première solution des 8-reines en environ 38 min avec le code suivant:
Code : Tout sélectionner
1:X=X-1:IF X=0 GOTO 7
2:W=A(X)-A(Y):IF ABS W IF ABS W<>Y-X GOTO 1
3:X=Y,A(Y)=A(Y)-1:IF A(Y) GOTO 1
4:Y=Y-1:IF Y GOTO 3
5:BEEP 1:PRINT V
6:"Z"CLEAR :INPUT Z
7:Y=Y+1,A(Y)=Z+1:IF Y>Z BEEP1:V=1+V,Y=Z:PRINT A;B;C;D;E;F;G;H
8:GOTO 3
La partie qui teste si deux reines sont en conflit est volontairement aux lignes 1: et 2: afin de limiter au maximum le temps cumulé des très nombreux GOTO 1
Les ligne 2: et 3: sont en fait la partie sous le label Lbl E qui décrémente position testée et indice de colonne.
La ligne 7: est un peu loin, mais comme elle est longue, la mettre au début du programme ralenti tous les sauts. Il y a peut-être moyen d'optimiser un peu en trouvant un meilleurs compromis. Mais c'est difficile, il ne faut pas oublier qu'il n'y aura au total que 2057 sauts vers la ligne 7: alors que les lignes 2: ou 3: compte pour respectivement 15720 et 1965. Là où les lignes 1: et 2: correspondent à 42338 passages.
Voilà le type de considérations qui permettent de gagner quelques heures, car avec son meilleurs rendement, je peux espérer avoir le listing des 92 solutions en moins de 10 heures même sur ma Ti58C qui prend son temps...
Juste que ce serai bien si j'avais une PC-100...
... trop fainéant pour noter 92 solutions
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
Re: A jouer aux reines avec une calculette de presque 40 ans !
Un superbe article comme toujours . Avec la Ti-58 en vedette en plus
Dominique
Re: A jouer aux reines avec une calculette de presque 40 ans !
Dans Mathématique élémentaire d'un point de vue algorithmique, Arthur Engel, Cedic, 1979 il y avait un chapitre consacré à ce problème.
Copie de la page avec le prog. et les 92 solutions
Copie de la page avec le prog. et les 92 solutions
Re: A jouer aux reines avec une calculette de presque 40 ans !
Bonjour, Il me semble que c'est l'algorithme classique utilisé et il a l'avantage d'être tres lisible présenté comme ça.
EDIT : A la relecture ce programme ne me semble pas si clair que çà... Sortir et rentrer dans des boucles avec des GOTO me semble une bien mauvaise pratique :/ pas retrouvé mon programme 502P de l'époque dans la marge de l'OP, juste une référence à un K7 perdue depuis bien longtemps. En marge j'avais noté 11'53" ce qui était très bien pour l'époque et probablement même la plus rapide versus ses concurrentes. Si je me trouve un peu de temps, je vais le réécrire pour 602/603P et une version graphique sur Amstrad CPC
Je me souviens du plaisir de voir ma Casio 502P exploser le temps des TI et HP dans les années 198x ;D Je dois toujours avoir le prog écrit dans les marges d'un vieil "Ordinateurs de Poche"
Modifié en dernier par Gilles59 le 27 juil. 2022 08:53, modifié 1 fois.
Casio FX-502P /602P / 603P / FX180P+ / FX4000P / TI57 / TI66 / TI74 Basicalc / TI95 Procalc / HP12C / HP15C LE / DM41L / HP 30B / HP39GII / HP 48SX USA / 49G / 49g+ / 50G / 50G NewRPL / HP Prime / Oric 1 / Amstrad CPC 6128+ CM14 et MM12 / Alice 32
Re: A jouer aux reines avec une calculette de presque 40 ans !
@c.ret... Tu dis "calculette de presque 40 ans"... Mais en fait la TI58 à presque 45 ans et la 58C 43ans ;D Mais peut-être évoques-tu l'âge précis de _ta_ calculatrice.
Casio FX-502P /602P / 603P / FX180P+ / FX4000P / TI57 / TI66 / TI74 Basicalc / TI95 Procalc / HP12C / HP15C LE / DM41L / HP 30B / HP39GII / HP 48SX USA / 49G / 49g+ / 50G / 50G NewRPL / HP Prime / Oric 1 / Amstrad CPC 6128+ CM14 et MM12 / Alice 32
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Re: A jouer aux reines avec une calculette de presque 40 ans !
Oui, c'est cela, son numéro de série (820874A ATA4681) laisse penser qu'elle n'aura quarante ans que le mois prochain.
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
- zpalm
- Fonctionne à 9600 bauds
- Messages : 2936
- Enregistré le : 03 mai 2008 15:33
- Localisation : Grenoble
Re: A jouer aux reines avec une calculette de presque 40 ans !
ATA4681: fabriquée à Abilene, Texas semaine 46 de 1981. Elle a eu 40 ans l’année dernière
Re: A jouer aux reines avec une calculette de presque 40 ans !
Hello,
Enorme benchmark de Xerxes sur ce thème avec une foultitude de machines. Il faut le modifier pour afficher les solutions trouvées mais c'est intéressant. Les versions 502-602-603P sont déjà bien optimisées en première lecture.
https://www.hpmuseum.org/cgi-sys/cgiwra ... i?read=700
Enorme benchmark de Xerxes sur ce thème avec une foultitude de machines. Il faut le modifier pour afficher les solutions trouvées mais c'est intéressant. Les versions 502-602-603P sont déjà bien optimisées en première lecture.
https://www.hpmuseum.org/cgi-sys/cgiwra ... i?read=700
Casio FX-502P /602P / 603P / FX180P+ / FX4000P / TI57 / TI66 / TI74 Basicalc / TI95 Procalc / HP12C / HP15C LE / DM41L / HP 30B / HP39GII / HP 48SX USA / 49G / 49g+ / 50G / 50G NewRPL / HP Prime / Oric 1 / Amstrad CPC 6128+ CM14 et MM12 / Alice 32
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Re: A jouer aux reines avec une calculette de presque 40 ans !
Ah! Merci pour le lien, à sa réception j'ai (un peu) cherché, mais comme un crét... , je n'ai pas pensé au site de Datamath. Impardonnable !!
Bon, il faut donc que je modifie le titre! Ou je le laisse come cela, ce n'est pas très poli de rappeler son âge à une dame.
Oui j'ai vu, attention, l'objectif des codes est un peu différent; ils ne servent pas à afficher les solutions, uniquement à les énumérer. Ce qui fait qu'ils ont un peu plus simples. Par ailleurs, les codes pour TI59/TI58 sont très proches du mien sans pour autant tirer partie de l'astuce du RST.Gilles59 a écrit : ↑27 juil. 2022 09:41Enorme benchmark de Xerxes sur ce thème avec une foultitude de machineshttps://www.hpmuseum.org/cgi-sys/cgiwra ... i?read=700
.
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
Re: A jouer aux reines avec une calculette de presque 40 ans !
L'auteur de l'article semble avoir fait tourner son programme sur une TI-58.C.Ret a écrit : ↑27 mai 2022 23:12 Alors, je me suis demandé si en utilisant exactement le code d'Alain, j'obtenais moi aussi 52 min pour la première solution du problème à 8-Reines.
Et non, avec ma machine, j'obtiens la première solution au bout de 1h27' au lieu des 52 min annoncées !
Mince, j'ai une Ti-58C lente ??
Or, si ne m'abuse, j'avais lu que TI-58C était moins rapide que la TI-58 (elle-même plus lente que la 59).
Peut-être que quelqu'un confirmera… ?
Bruno
Sanyo CZ-0124 ? TI-57 ? HP-15C ? Canon X-07 + XP-140 Monitor Card ? HP-41CX ? HP-28S ? HP-50G ? HP-50G
Sanyo CZ-0124 ? TI-57 ? HP-15C ? Canon X-07 + XP-140 Monitor Card ? HP-41CX ? HP-28S ? HP-50G ? HP-50G
Re: A jouer aux reines avec une calculette de presque 40 ans !
Hello. [edit v2] Voici ma version casio 602p/603p qui tient en 66 pas. On saisi la taille de l’échiquier puis on lance le programme, par exemple P0.
Par exemple 4 P0 trouve ->3142 en quelques secondes puis après EXE -> 2413 et enfin -> 0000 quand plus de solutions.
En 8x8 La première solution est trouvée 7mn03 sur 602p. Ça devrait faire 2mn25 sur la 603p que je n’ai pas sous la main vu le ratio de vitesse de 2,9. Vu qu’il y a un timer sur la 603p j’aurai le temps exact.
La première solution trouvée est 84136275 puis 83162574 … J’ai en tête une version graphique sur cpc ensuite.
En théorie ça peut résoudre des tailles 80x80. En théorie lol. Ça semble moins rapide que ce que j’avais fait dans le temps sur la 502p (au prorata de la vitesse) mais pas sûr.
Sur la TI58C plus lente que la TI58 ça me rappelle vaguement quelque chose.
Par exemple 4 P0 trouve ->3142 en quelques secondes puis après EXE -> 2413 et enfin -> 0000 quand plus de solutions.
En 8x8 La première solution est trouvée 7mn03 sur 602p. Ça devrait faire 2mn25 sur la 603p que je n’ai pas sous la main vu le ratio de vitesse de 2,9. Vu qu’il y a un timer sur la 603p j’aurai le temps exact.
La première solution trouvée est 84136275 puis 83162574 … J’ai en tête une version graphique sur cpc ensuite.
Code : Tout sélectionner
MAC
MinF
LBL0
MR00 x=F GOTO4
ISZ
MRF IND Min00
LBL1
MR00 Min19
LBL2
1 M-19
MR19 x=0 GOTO0
IND MR00 - IND MR19 = x=0 GOTO3
ABS + MR19 - MR00 = x=0 X=F GOTO2
LBL3
IND DSZ GOTO1
DSZ GOTO3
LBL4
0 Min1F
« -> »
LBL8
1 M+1F IND MR1F « ;# »
MR1F x>=F x=0 GOTO8
« ; »
HLT GOTO3
Sur la TI58C plus lente que la TI58 ça me rappelle vaguement quelque chose.
Modifié en dernier par Gilles59 le 14 août 2022 11:31, modifié 1 fois.
Casio FX-502P /602P / 603P / FX180P+ / FX4000P / TI57 / TI66 / TI74 Basicalc / TI95 Procalc / HP12C / HP15C LE / DM41L / HP 30B / HP39GII / HP 48SX USA / 49G / 49g+ / 50G / 50G NewRPL / HP Prime / Oric 1 / Amstrad CPC 6128+ CM14 et MM12 / Alice 32