Je ne suis pas surpris d'apprendre que ce qui fonctionne sur une HP28S, fonctionne de même sur les suivantes, HP a veiler à la compatibilité ascendante et surtout à éviter autant que possible des "variations" entre les modèles pour éviter des variation du standard qui conduiraient inmanquablement à des erreur et confusion.
L'exception est peut-être la fonction d'intégration qui n'a pas les mêmes argument entre les HP3x/4x/50 et les HP2x.
Gilles59 a écrit :Je ne comprends pas bien. As tu un ex ?
L'exemple le plus simple est celui qui permet d'obtenir les éléments d'une matrice:
Supposons que l'on a une matrice M, par exemple de 4x5 :
Code : Tout sélectionner
[[ 89 70 74 30 52 ]
[ 49 82 37 7 85 ]
[ 41 8 81 79 33 ]
[ 9 2 21 58 21 ]]
'M' STO
Et que l'on souhaite afficher les 6 éléments se trouvant au centre de M, on peut par exemple écrire le programme suivant qui utilise deux compteurs locaux i et j :
Code : Tout sélectionner
« 2 3 FOR i
2 4 FOR j
'M' { i j } GET @ obtient M(i,j)
1 DISP 5 WAIT @ affiche et attend 5 secondes
NEXT
NEXT
»
Dans ce programme, la liste { i j } contenant deux variables locales est 'évaluée' par l'instruction GET en fonction des valeurs des variables en question.
Ce qui constitue une exception de la régle en vigueur sur le HP28S, qui dit que l'évaluation d'une liste donne la liste elle-même.
Sinon, j'ai toujours un peu de mal avec l'instruction ADD.
D'abord, pourquoi ne pas l'avoir appelée SUM et y-a-t-il l'instruction équivalente mais pour le produit des éléments de la liste.
{ 1 2 3 4 5 } SUM renverrai 1+2+3+4+5= 15
{ 1 2 3 4 5 } PROD renverrai 1*2*3*4*5= 5! = 120
Ensuite, l'idée de 'vectorialiser' ou paralléliser les calculs avec des liste en argument est excellente, c'est une idée qui est à base de pas mal d'outil de programmation matriciel (comme MatLab et autre MathCad) mais sans l'inconvénient de devoir créer de nouveaux opérateurs ou d'avoir à ajouter un opérande marquant la 'vectorisation du calcul':
{ 1 2 3 4 5 } SQ renvoi { 1 4 9 16 25 }
DEG { 0 45 90 135 180 } SIN renvoi { 0.000 0.707 1.000 0.707 0.00 }
DEG { (1,30) (2,60) (3,90) } R->P renvoi { (0.866,0.500) (1.000,0.000) (1.732,3.000) }
{ 1.1 -2.2 3.3 -4.4 -5.5 } ABS FLOOR renvoi { 1 2 3 4 5 }
etc
On peut ainsi utiliser toutes les fonctions disponibles, très astucieux (et fort utile en algébre linéaire et autre calculs matriciels)
Et rien ne nous oblige à n'utiliser que des fonctions unaires, on pourrait étendre le principe aux fonction binaire et ternaire :
{ 1 2 3 4 } { 5 6 7 8} R->C retournerai { (1,5) (2,6) (3,7) (4,8) }
{ 12 13 14 } { 7 8 9 } MOD retournerai { 5 5 5 }
DEG { 1 2 3 } { 30 60 90 } P->R renverrai { 0.866 1.000 0.000} { 0.500 1.732 3.000 }
Et là, j'ai un soucis avec la fonction binaire d'addition + qui se confond avec ADD (instruction de concaténation et SUM dans la version actuellement implanté dans les HP)
Si l'on suit la logique de l'idée géniale précédente :
{ 12 13 14 } { 7 8 9 } + devrait retourner { 19 21 23 } et non pas { 12 13 14 7 8 9 }
Pour obtenir cette dernière liste, on utiliserai l'opérateur de concaténation (CONCAT ou ADD pour faire court)
"Lapin" "Garou" ADD retournerai "LapinGarou"
'A' 'B' ADD retournerai 'ADD(A,B)'
{ 12 13 14 } { 7 8 9 } ADD retournerai { 12 13 14 7 8 9 }
Cet opérateur est binaire (il prend deux arguments et les assemble, il peut donc être lui aussi utilisé pour une opération vectorialisée (ou parallèlisée):
{"Lapin" { 12 13 14 } 45 A} {"Garou" { 7 8 9 } 23 B } ADD donnerai donc {"LapinGarou" {12 13 14 7 8 9} [45 23] ADD(A,B)}
La question est alors, comme pour SORT, mais que donne alors 2 "Truc" ADD ? Où faut-il arrêter la logique d'évaluation ? Comment convertir un objet d'un type à un autre ?
C'est pourtant une astuce que l'on utilise souvent, par exemple, convertir en chaîne de caractère pour modifier un objet avant de l'évaluer à nouveau dans son type inital.
On voit donc poindre à l'horizon un point interessant du RPL, il permet contrairment au RPN de manipuler des objets de différents type (scalaire, vecteur, matrice, liste, chaine de caractères, entier long, nombre binaire/hexa, nombres complexes, expression algébrique, programmes, etc), mais la majorité des instructions et opérande qu'il utilisent ne sont pas définies pour tous ces types, et parmi lesinstruction les plus 'universelles', celles qui sont définit pour pratiquement tous les types possibles, rares sont celles qui le sont égalemement pour des arguments de type croisés.
Le CATALOG des instructions RPL n'est pas exhaustif, dans le sens ou chaque instruction n'est implémenté que pour un jeu d'arguments de type définis et non pour tous les jeuxd'arguments de type quelconques.
Il est tard, je vous laisse méditer sur ce point quasi-philosophique du RPL, qui partage là un aspect rencontré dans beaucoup de langage de programmation utilisant la notion de classe et en ce point, il diffère fondamentalement du LISP où tout est liste et uniquement liste ou atome.
