Forum

Bonsoir,

Prendre le risque de démonter pour un seul segment, c'est un peu comme changer d'écran LCD pour un seul pixel mort !

Non non Treza, il n'y a pas de quoi être désolé !

Au contraire, je trouve toutes ces précisions fort interessantes et instructives !

C'est donc tout à fait dans l'esprit de ce M.P.O. qui d'aspect simple mène grâce aux efforts et à l'érudition des participants prend de l'épaisseur et attise les curiosiés...


Comme il s'agit tout de mêm d'un MPO, je me permet de "raccourcir" le code BASIC de baborhum (On arrêtera la boucle par ON lorsuqe l'on jugera que la racine affichée a suffisemment convergée vers la racine carrée !

Effectivement, la méthode de Héron converge assez vite :

Ex.1 : racine de 25 en 6 itérations.
Ex.2: Et à peine plus long pour 150225 (14 itérations).
J'avais envisagé une méthode basée sur la dichotomie. Mais, elle semble plus longue.

Bonjour à toutes et à tous...


En cet fin d'août, je propose un petit exercice simple dans la plus pure des traditions des M.P.O. (Misez Petit, Optimisez !).

Pour une fois, ce MPO ne s'adresse pas uniquement aux calculatrices programmables et aux monstrueux ordinateurs déguisés en calculette de poche, mais également aux calculatrices non programmables, aux calculatrices de comptable, aux quatre-opérations, calculateur mécanique et autres stylo-gadgets...

En effet, l'exercice est fort simple sont attendus tout autant les programmes fort sophistiqués que les simples méthodes opérationnelles notée sur un coin de feuille...

Il s'agit en effet, dans la plus pure tradition des M.P.O., de donner le meilleur (selon vous) programme ou mode opératoire à utiliser sur votre (vos) calculateur(s) préféré(s) qui permette d'extraire la racine carrée d'un nombre positif quelconque !

Bien, évidemment, il est interdit d'utiliser les fonctions racine-carrée, puissances, racine n-ième, fonctions logarithmes ou exponentielles, ... lorsque que celles-ci existent sur votre calculateur. Ce serait de la gruge !


Pour vous aider, j'ai retrouvé en parcourant les sujets de notre forum cette méthode d'extraction :
Extraction d'une racine avec un stylo t un block-note

Comme à notre habitude, les méthodes et programmes seront examinés et évalués de façon collégiale en fonction de leur taille (c’est tout de même un MPO), mais aussi de leur rapidité, efficacité, précision, … et tout autre paramètre esthétique, ergonomique ou fonctionnel…

Tiens, je croyais que la CASIO FX-702P se programmait en BASIC !!???

babaorhum a écrit :Mais au fait ...
Sur une horloge révolutionnaire, il n'y a que le cadran qui change ; la position des aiguilles est la même que sur l'horloge Royale,

Je n'en suis pas sûr, de minuit à miniuit la petite aiguille de ma montre à goussets fait deux tours complets. Son cadran marque les 12 heures.

Une montre révolutionaire avec un cadran comme celui de la photographie du preier post ne fait qu'un tour de cadran par jour !
La montre révolutionaire décimale fonctionne donc exactemetn deux fois moins vite qu'une montre de l'ancien régime.

D'où mon code pour HP-28S:

Désolé pour cette réponse tardive.

Mais je ne pourrais pas être des vôtres demain! A grand regret, je dois me rendre à Berlin pour les trois prochains jours.

Heureusement, l'hôtel aura le Wifi, je pourrais être connecté et suivre à distance les comptes-rendus ...

Bonjour,

Je suis un peu pris professionellement en ce moment, pas eut le temps de m'y mettre sérieusement !

J'ai une approche encore une fois un peu diffèrente.
La résolution que je propose est basée sur un coefficient de précision.

Cela vient du fait qu'il y a longtemps, j'avais essayer de programmer (en BASIC pour CBM 8bit) une horloge graphique affichant les secondes (avec une troteuse).

Pour simplifier le code et surtout avoir un affichage en un temps suffisement court, je pré-calculais les coordonnées des aiguilles dans des tableaux. Ce qui permettait presque d'avoir un affichage à la seconde . Enfin, presque sur un CBM 4096 (en BASIC je le rapèle).


En effet, la question posée par Marge a pour solutions des série de 'coïncidences' qui dépendent allégrement de la précision du déplacement des aiguille que l'on a le droit de considérer.

Si par exemple on ne peux pas considérer des déplacements de 30° d'angle, alors les heures hh:mm:ss sont alors
00:00:00 ( 0°)
01:05:05 ( 30°)
02:10:10 ( 60°)
03:15:15 ( 90°)
04:20:20 (120°)
05:25:25 (150°)
06:30:30 (180°)
07:35:35 (210°)
08:40:40 (240°)
09:45:45 (270°)
10:50:50 (300°)
11:55:55 (330°)
12:00:00 ( 0°) c'est en fait la première coïncidence.

Mauis en fait, aucune de ces heures, n'ai réaliste, car les aiguille ne font pas des bons de 30°, elles se déplacent de poux-ième.

Le nombre de solutions envisageables dépend donc directement de cette tolérence.

Je suis persuadé qu'il y a des dizaines de lieux et de situations où une régle à calcul, un sextant, un vernier, un curvimètre, un dosimètre, un sextant, un pendule, un tire-bouchons, ... sont bien plus utiles et efficaces qu'une calculatrice, un pocket ou même un i/smart-phone.

Que ce soit dans le Module de Commande d'une capsule Appolo, une tourelle de tir, la salle des cartes, la passerelle d'un navire, le cockpit d'un avion, le pupitre de commande d'une chaine de fabrication, une centrale nucléaire ou d'un accélérateur de particule, au fond d'une mine ou d'une carrière ...

Et je pense que cela sera encore vrai un certain temps, tant que l'on laissera des hommes et des femmes à ces postes clefs....
Evidemment quand des robots et des automates nous auront remplacés à tous ces postes de commande et de pilotage, alors effectivement ... il ne nous restera plus qu'à jouer sur nos écrans...

Donc, si je comprends bien c'est un Galaxy Note II factice comme ceux que l'on trouve dans les vitrines des banques, supermarchés, boutiques, etc, qui vendent des téléphones et autres forfaits...

Ce type d'article est donc si rare et si demandé qu'un enchéreur est prêt à mettre plus de 100€ pour en acquérir un !?
Ce doit être quelqu'un qui a une boutique et qui en a besoin pour mettre dans sa vitrine ?

Je m'attendais à ce qu'un boitier factice coûte dans les 15€ au maximum (c'est pour cela que je ne casse pas les présentoirs à carrouf). Mais si chaque 'factice' fait environ 100€ ...
... il faut que je retrouve ma barre à mine et mon peid de biche.


Ou alors un petit oiseau s'est fait avoir, il croyait peut-être pouvoir acquérir ce type d'équipement pour 1/4 du prix ?

Merci messieurs pour ces pertinentes informations (surtout à jxano pour son excellente démonstration).

Je peux donc optimiser mon programme sans aucune crainte : EDITION: raccourci le programme de 6 octets

Paul Tergeist a écrit :sigma(i=1 à n,i^3)= carré( sigma(i=1 à n, i) )

MPO ?
1+2+3+4+5 = 15 et 15^2=225
1+8+27+64+125 = 255

Ah! Ouai !

Démonstration ?

Il n'y a pas de quoi être déçu. Avec nos calculettes ce qui compte n'est pas la vitesse absolue, mais bien l'ingéniosité mise en oeuvre pour tirer le meilleurs profit du matériel.

Qui aurait imaginé en 1984 que l'on fasse ce type de calculs sur un PC-1600 !!

Le jeu de la Vie de Conway est toujours un sujet de recherche et même les plus gros systèmes ne calculent pas vite (proportionnelement à leur puissance biensûr !).

En tout cas l'approche 'descendante' pour éviter les doubles (ou triples) comptage est execellente.

Ouups.

Concernant le mage à utiliser, vu qu'il s'agit d'arbres, d'étoiles et que l'idée est tirée par les cheveux, je pensais à un mage comme ce type là:


Paul, tu remarquera qu'en fait cela fait un oeuf !

Gilles59 a écrit : EDIT : Ok sur la vraie calc (j'utilise ENVOI entre l'émulateur et la calc ca marche à tout coup), mais c'est nettement plus lent et l'effet 'balayage' de haut en bas accentué, mais çà reste super

Merci pour l'info.

En fait pour avoir un aperçu réaliste sur l'émulateur il suffit de déplacer la boucle de temporisation (while t-Ticks) de façon à freiner le balayage.

Sur l'HP39gii, il est facile aussi de masquer ce balayage.
Par exemple en faisant l'inverse : dessiner les nouvelles cellules dans G1 puis uniquement à la fin du balayage recopier G1 dans G0. ON laisse alors l’image fixe pendant le balayage suivant.

En pratique, cela revient à inverser dans mon code G0 et G1. La première version a cependant l’avantage de « voir travailler » la machine, faciliter la mise au point et éviter de ce demander si elle n’est pas plantée !

Je n’ai pas eut le temps cette semaine, mais je suis sur un perfectionnement du principe même.

Au lieu à chaque cycle de balayer la « boite de culture » (boucle FOR x FOR y emboité, suivit des boucles FOR a et FOR b pour compter les 8 voisins). Sur notre exemple de boite de culture de 30x30 cela fait donc 10800 tests (9000 pour le comptage et 1800 pour les deux règles de vie).
Sur mon Commodore, les boucles FORa et FOR b n’existent pas, elles sont remplacée par 7 appel à un sous-programme et il y a un court-circuit si w > 3 (pas la peine de compter jusqu’à .
Mais l’économie est minime car rare sont les cas où la grille est noire de monde !

Je suis en train de me demander s’il n’est pas plus rentable d’utiliser une approche diffèrente.

De la même façon que les « mages de la zone de balayage » sont mises à jour à chaque fois que l’on allume (ou éteint) une « cellule », il est possible de mémoriser dans une pile les cellules qui devront être ajoutées au ‘balayage suivant’ (c'est-à-dire les 8 cellules voisine lorsque l’on fait naitre une cellule) et éventuellement retirer de cette pile celles qui n’ont plus de raison d’y figurer lorsque l’on éteint une ‘cellule’.

Si l’on trouve le moyen de faire cela avec une pile facile à parcourir (il ne faut pas que cette pile entraine un balayage supérieur à celui de la méthode classique) et à maintenir. Alors on aura quelque chose qui ‘vit’ au rythme des naissances et des morts et qui ne sera plus ralenti lorsque la taille de la culture rempli l’écran.

Je n’ai pas eut le temps d’approfondir, mais utiliser une pile du style ‘tas binaire ordonné’ (Treap) devrait convenir.
L’astuce étant d’indexer les cellules de coordonnées (x,y) dans un premier TREAP qui référencie les cellules selon x (il y a plus de colonnes x que de ligne y sur l’écran) qui pointe vers une série de TREAP secondaires qui chacun référencie les cellules selon y (les lignes donc) pour cette colonne x.

Cette structure de donnée doit permettre de mémoriser l’ensemble des cellules à ‘analyser’, qu’elles soient ‘mortes’ (pour l’instant) ou ‘vivante’ (cet état lui aussi est précaire) tout en permettant :
- D’ajouter facilement les cellules voisines lorsqu’une ‘cellule’ nait.
- De retirer les cellules sur les ‘marges’ lorsqu’elles se retrouvent trop éloignées de cellules vivantes. Car dans ce cas, rien ne sert de perdre son temps à les analyser, elles ne changeront pas d’état tant qu’une cellule ne nait pas à proximité.

Pour le moment, cette structure de données n’a pas à mémoriser l’état des cellules (qui est donné directement par ‘lecture du graphique’ (GETPIX_P). Mais j’en suis à me demander si cette information ne pourrait pas être facilement incluse dans ce tas de tas.
Et si c’est possible (et rentable) cela signifie que l’on peut écrire un programme sans utiliser de GETPIX, donc économiser une copie de l’écran et ouvrir la porte aux machines moins puissantes ou qui n’ont pas de GETPIX (par exemple les HP-28S)