Générations de Fractales: Casio,Sharp,Sanco,Hp,Amstrad...

[Gilles59]

J'ai eu quelque décalages sur la FA-10 et le PB-700, du coup j'ai défini un X0,Y0 que j'utilise pour finir la fractale.

Du à la mécanique du traceur ou aux calculs selon toi .?

Une petite animation fractale des images générés par HP50 en cliquant là :

http://imagik.fr/uploads/330771

[gege]

Code : Tout sélectionner

    NEXT 3. PR ^ INV 'L' STO 1. DUP DUP2 0. -> X1 Y1 X2 Y2 DI
    « DEG ERASE { # 0h # 0h } PVIEW 1. CD SIZE

Ah aaaah pris en flagrant délit de création d'un niveau de programme supplémentaire ( << >> ) sans raison autre que de pouvoir créer des variables !!!
Je trouve qu'il devrait y avoir un autre moyen moins moche, non ?

Code : Tout sélectionner

      FOR I CD I I SUB "G" ==
        IF
        THEN 60.
        ELSE -120.

Pas trop conforme à la logique simple qui voudrait que l'on écrive IF <test> THEN <trucs> ELSE <machins> END...
Mais ce style est totalement typique sur RPL.
Je me demande pourquoi HP n'a pas simplement créé un verbe IFTHEN sans faire semblant d'avoir besoin de ce IF séparé du THEN ? Surtout que côté interpréteur, l'utilité du IF ne parait pas claire.
Si quelqu'un peut m'expliquer ??

Bizarre
G.E.

[gege]

J'aurai cru que les erreurs d'arrondis allaient générer des défauts et bien pas du tout....

Comme je le disais plus haut, si tu as 10000 segments et que ça représente 50000 opérations, chacune précise à 10^-8, l'erreur cumulée est très faible, on s'attend à moins de 10^-3.

Tout vient de la précision ahurissante de nos machines.
G.E.

[Gilles59]

Code : Tout sélectionner

    NEXT 3. PR ^ INV 'L' STO 1. DUP DUP2 0. -> X1 Y1 X2 Y2 DI
    « DEG ERASE { # 0h # 0h } PVIEW 1. CD SIZE

Ah aaaah pris en flagrant délit de création d'un niveau de programme supplémentaire ( << >> ) sans raison autre que de pouvoir créer des variables !!!
Je trouve qu'il devrait y avoir un autre moyen moins moche, non ?
G.E.

Bsr... En fait çà sert à définir le niveau d'existence des variables locales.

Code : Tout sélectionner

-> a
<<
      .
      . Ici je vois a, 
      .

>>
A partir de là, je ne vois plus a

Perso je trouve çà logique. Dans beaucoup de langage tu ne peux pas créer des variables n'importe où dans le programme. Ca se fait en début de programme (en Pascal par exemple).

mais pour faire autrement, plusieurs solutions

1/ Utiliser des variables globales

'a' STO On crée une variable globale et le tour est joué

Cette variable sera alors persistante et continuera a exister à la fin de l'exec du prog. On peut forcer sa suppression en fin de prog avec 'a' PURGE
Comme toujours en RPL, on peut utiliser une liste genre { 'a' 'b' 'c' 'd' } PURGE pour supprimer une série de variables. C'est d'ailleurs tres pratique pour 'nettoyer' les objets des menu : {} puis clic sur tout ce qu'on veut supprimer puis PURGE

2/ On peut initialiser toutes les variables locales en début de prog, un peu comme en Pascal ou autre. C'est ce que je fait en général. Ca nécessite de les initialiser avec une valeur ce qui est nécessaire car toutes les 'variables' ( je parlerai plutot d'objets en RPL) doivent être typés.

TYPE renvoi le type d'objet au niveau 1 de la pile (est-ce une chaine de caractére ? un entier ? un réel ? un complexe ? une matrice ? un vecteur ? un fichier graphique? une liste ? un programme ? etc. Cela permet d'ailleurs de créer assez facilement un programme "polymorphe" qui fonctionne à la fois avec des réels ou des complexes ou autre objets... Bref un objet en RPL doit avoir un type d'où l'initialisation obligatoire des variables locales.

3/ On peut aussi utiliser ce que la doc US appelle une "compiled local variable". Je ne les utilise pas et à tord sans doute. La durée de vie de ces variables est égale à la durée de vie d'exécution du programme qui la crée mais elles sont aussi accessibles à tous les sp externes appelés .Elle se purgent automatiquement à la sortie du programme. D'apres la doc, ce sont les variables les plus "rapides"

[Gilles59]

Code : Tout sélectionner

      FOR I CD I I SUB "G" ==
        IF
        THEN 60.
        ELSE -120.

Pas trop conforme à la logique simple qui voudrait que l'on écrive IF <test> THEN <trucs> ELSE <machins> END...
Mais ce style est totalement typique sur RPL.
Je me demande pourquoi HP n'a pas simplement créé un verbe IFTHEN sans faire semblant d'avoir besoin de ce IF séparé du THEN ? Surtout que côté interpréteur, l'utilité du IF ne parait pas claire.
Si quelqu'un peut m'expliquer ??

Bizarre
G.E.

slt Gege

Tu peux tout à faire : IF <test> THEN <trucs> ELSE <machins> END
C'est la syntaxe précisée dans la doc. Je fais comme çà d'ailleurs. Ce que fait kweeky fonctionne et effectivement tu a compris que le IF ne sert pas à grand chose en RPL sauf faciliter la lecture (ce qui est entre le IF et et le THEN est le test pour que ce soit clair) . De mémoire c'est assez différent en FORTH ou le IF se place forcément apres le test si je me souviens bien et le THEN apres ce qui s'exécute si vrai dans une logique 100% polonaise inverse

La logique RPL 'ulltime' est d'utiliser IFT et IFTE. <test> <ce que je fais si vrai> <ce que je fais si faux> IFTE

[ledudu]

Code : Tout sélectionner

5 REM Canon - X-07
10 A=30/180*3.1459:CLS
20 INPUT"Profondeur:";P:CLS:PRINT"Niveau:";P
30 D=400/3^P
40 X0=3:Y0=0
50 X=X0:Y=Y0
60 LPRINT CHR$(17)
70 LPRINT[2,1]"Niveau:";P
80 LPRINT"--------"
90 FOR J=1 TO 9:LPRINT" ":NEXT J
100 LPRINT CHR$(18)
105 LPRINT "M "+STR$(X)+","+STR$(Y)+","+  STR$(X)+","+STR$(Y)
110 FOR N=1 TO 3*4^P
120 S=-2
130 IF P=0 THEN 180
140 FOR I=1 TO P
150 J=(4^I)/2
160 IF INT((N+J/2)/J)=(N+J/2)/J THEN S=1
170 NEXT I
180 X=(X+D*COS(A))
190 Y=Y+D*SIN(A)
200 A=A+60*S/180*3.1459
210 IF N=3*4^P THEN X=X0:Y=Y0
220 LPRINT "D "+STR$(X)+","+STR$(Y)
240 LOCATE 0,2:PRINT N;"/";3*4^P;":"
250 NEXT N

Chargé puis récupéré avec basx07 & listx07 de Marcus

[Gilles59]

Joli

J'avais ce genre de bestiole (mini traceur 4 couleurs) du temps ou j'avais un ORIC mais tout revendu

[ledudu]

J'ai eu quelque décalages sur la FA-10 et le PB-700, du coup j'ai défini un X0,Y0 que j'utilise pour finir la fractale.

Du à la mécanique du traceur ou aux calculs selon toi .?

C'est le calcul, j'ai eu un plantage avec le Line m'obligeant à faire un round... J'aurais peut-être pû éviter mais j'ai pas creusé, ça marche bien comme ça.

Une petite animation fractale des images générés par HP50 en cliquant là :
http://imagik.fr/uploads/330771

Elle est top, super.

[kweeky]

Code : Tout sélectionner

    NEXT 3. PR ^ INV 'L' STO 1. DUP DUP2 0. -> X1 Y1 X2 Y2 DI
    « DEG ERASE { # 0h # 0h } PVIEW 1. CD SIZE

Ah aaaah pris en flagrant délit de création d'un niveau de programme supplémentaire ( << >> ) sans raison autre que de pouvoir créer des variables !!!
Je trouve qu'il devrait y avoir un autre moyen moins moche, non ?

Je plaide coupable. La raison de cet acte abject est simple : j'ai commencé par faire deux programmes : un qui calculait la chaine de déplacements, l'autre qui traçait à partir de cette chaine. Mais je les ai ensuite fusionné pour produire une version "stand alone". La création de variables locales est certes "pas très propre", mais plus propre que la création de "vrais" variables qui vont envahir le répertoire en cours.

Code : Tout sélectionner

      FOR I CD I I SUB "G" ==
        IF
        THEN 60.
        ELSE -120.

Pas trop conforme à la logique simple qui voudrait que l'on écrive IF <test> THEN <trucs> ELSE <machins> END...
Mais ce style est totalement typique sur RPL.
Je me demande pourquoi HP n'a pas simplement créé un verbe IFTHEN sans faire semblant d'avoir besoin de ce IF séparé du THEN ? Surtout que côté interpréteur, l'utilité du IF ne parait pas claire.
Si quelqu'un peut m'expliquer ??

Bizarre
G.E.

Là je suis d'accord avec toi, et je ne vois pas l'intérêt de la séparation du IF et du THEN alors qu'on utilise la notation polonaise inverse. C'est pourquoi j'utilise cette structure qui peut sembler bizarre de prime abord. Je serai tout à fait d'accord pour le remplacement de IF et THEN par un mot unique IFTHEN. On pourrait objecter que cette séparation est utile quand on utilise la HP en mode ALG, mais ça ne tient pas la route car les mots IF et THEN existent depuis la 28.

Mais bon, comme je l'ai déjà dit, je ne suis qu'un béotien, même pas informaticien (ouuuuuhhh !!!! La honte !!!! )

[Marcus von Cube]

Chargé puis récupéré avec basx07 & listx07 de Marcus

[jxano]

Là je suis d'accord avec toi, et je ne vois pas l'intérêt de la séparation du IF et du THEN alors qu'on utilise la notation polonaise inverse. C'est pourquoi j'utilise cette structure qui peut sembler bizarre de prime abord. Je serai tout à fait d'accord pour le remplacement de IF et THEN par un mot unique IFTHEN. On pourrait objecter que cette séparation est utile quand on utilise la HP en mode ALG, mais ça ne tient pas la route car les mots IF et THEN existent depuis la 28.

Mais bon, comme je l'ai déjà dit, je ne suis qu'un béotien, même pas informaticien (ouuuuuhhh !!!! La honte !!!! )

Depuis la 28, ce mot existe en fait :

Code : Tout sélectionner

FOR I CD I I SUB "G" == 60. -120. IFTE

[C.Ret]

[On pourrait objecter que cette séparation est utile quand on utilise la HP en mode ALG, mais ça ne tient pas la route car les mots IF et THEN existent depuis la 28.

Nos messages se sont croisés.

Effectivement.

Il existe aussi deux instructions qui permettent les traitements conditionels IF...THEN...END et IF...THEN...ELSE...END mais qui respectent scrupuleusement la logique de pile post-fix du RPL:

Il s'agit des instructions IFT et IFTE :

Code : Tout sélectionner

IF x 0 > THEN "Positif" END                  s'écrit alors           x 0 > "Positif" IFT   ou         'IFT(x>0,"Positif")' 

et

Code : Tout sélectionner

IF x y == THEN "Egaux" ELSE "Differents" END      s'écrit       x y == "Egaux" "Differents" IFTE  ou   'IFTE(x==y,"Egaux","Differents")'

Mais les structure IF...THEN.... ne sont pas les seules où la position des termes n'est pas claire :
Essayer
0 DO 1 + UNTIL DUP 9 > END
et
0 DO UNTIL 1 + DUP 9 > END

Alors ?

[jxano]

Une chose qui m'étonne dans tous nos programmes c'est que les raccords sont parfaits. Par exemple dans le niveau 7 il a y un nombre de calcul considérable, d'avance, de tourne à droite ou gauche et malgré tout cela on tombe pile poil à la fin pour fermer la surface...

J'aurai cru que les erreurs d'arrondis allaient générer des défauts et bien pas du tout....

J'ai eu quelque décalages sur la FA-10 et le PB-700, du coup j'ai défini un X0,Y0 que j'utilise pour finir la fractale.

À première vue, pour résoudre ce problème, je commencerais par définir les déplacements en coordonnées entières dans un réseau de triangles équilatéraux. Je calculerais des coordonnées orthonormées seulement pour le tracé.

Au reste, les angles sont toujours multiples de 30°, donc les sinus et cosinus sont tous 0, +/- 1, +/- 1/2 et +/- racine(3)/2.

[Gilles59]

Mais les structure IF...THEN.... ne sont pas les seules où la position des termes n'est pas claire :
Essayer
0 DO 1 + UNTIL DUP 9 > END
et
0 DO UNTIL 1 + DUP 9 > END

Alors ?

Même logique ... Comme le IF, le UNTIL ne sert amha qu'à améliorer la lisibilité. Je pense que l'interpréteur RPL l'ignore tout simplement.
La logique (et la doc) veut que le test soit entre le UNTIL et le END , mais dans dans les faits ce qui importe c'est "quelle est la valeur logique au _sommet_ de la pile au moment du END ?"

En ce sens la syntaxe << 0 DO 1 + UNTIL DUP 9 > END >> est plus claire. Elle sépare clairement ce qui est dans la boucle et ce qui est dans le test. Mais l'autre proposition marche aussi bien (mais moins claire à la lecture)

Dans la doc il est dit pour DO...UNTIL...END :
"END remove the test result of the stack. If the value is zero,the loop clause is execute again; otherwise the exucution resumes following END" .

END retire le résutat du test du sommet de la pile. Si la valeur est égale à zéro, la boucle s'éxécute de nouveau; sinon le programme se poursuit après le END
En RPL FAUX est zéro , tout autre valeur est VRAI

Juste pour compliquer les choses , en Forth autre langage "de pile" la syntaxe est :
<test> IF <à faire si vrai> ELSE <A faire si faux> THEN;
Ca me semble peu logique.... Je verrai plutot
<test> IF <Si vrai> THEN <Si faux> ELSE;

RPL a bien fait amha de ne pas suivre Forth pour le coup. La syntaxe RPL utilisée comme precrit par la doc me plait bien :
IF <Test> THEN <Si vrai> ELSE <Si faux> END

Même si le IF n'est là que pour la déco !

[C.Ret]

Code : Tout sélectionner

0 DO 1 + DUP 9 == UNTIL END
0 DO 1 + DUP 9 UNTIL == END
0 DO 1 + DUP UNTIL 9 == END
0 DO 1 + UNTIL DUP 9 == END
0 DO 1 UNTIL + DUP 9 == END
0 DO UNTIL 1 + DUP 9 == END

Oui, il faut donc mettre UNTIL quelque part entre DO et END.

C'est tout l'inverse du C, on met les mots clefs des structures facilite la lecture du programme et ne sont pas interprété, sauf par un éventuel lecteur.
Déplacer un seul caractère dans un code C et c'est la Catastrophe.