dans quel ordre mettre les arguments ?
À l'inverse des calculettes et autres systèmes de programmation, AutoLISP n'interprète pas les opérations dans le sens convenu, c'est à savoir avant de commencer, et à admettre, car ce n'est pas négociable.
Les habitués des calculettes scientifiques HP sont déjà rompus à cette notation polonaise inversée, également appelée notation RPN (Reverse Polish Notation).
Par exemple, pour additionner 10 à 30, on ne va pas écrire 10+30 mais ( + 10 30 )
pour respecter la syntaxe AutoLISP :
La structure + 10 30 contenue dans une paire de parenthèses est appelée une expression, c'est la structure de base d'AutoLISP.
Dans tout programme AutoLISP cette notion d'expression est présente.
Notez la présence d'une espace entre la fonction et le premier argument ainsi qu'entre les deux arguments et aussi à la fin de l'expression, cette dernière n'est pas obligatoire, elle est simplement bienvenue et utile pour la lisibilité de l'expression.
Des expressions contenant des fonctions peuvent être passées en argument,
par exemple : additionner 2 à (4 divisé par 2)
AutoLISP va interpréter
(/ 4 2), 4 divisé par 2 et renvoyer 2
Puis interpréter
( + 2 2) -> 2 plus 2 et finalement renvoyer 4
L'affichage de la console LISP semble incomplet pour ce qui est des décimales d'un nombre issu d'une saisie écran ou d'un calcul, par exemple vous cliquez un point à l'écran, vous renseignez une variable avec ses coordonnées, et vous vous étonnez de l'affichage de ces dernières dans la console.
Tiens ! Ça alors !, ce ne sont pas les mêmes coordonnées que je trouve en demandant par la commande de renseignement dans AutoCAD les coordonnées du point ! (commande ID).
Rassurez-vous, ce n'est qu'une "paresse" d'affichage et la preuve on va l'obtenir en transformant en chaîne de caractères (STRING) les réels de la liste des coordonnées du point.
Faisons un test qui va faire apparaître ce qui semble un dysfonctionnement au prime abord, mettez la valeur 4 dans la variable LUPREC qui définit la précision d'affichage des unités et des coordonnées linéaires, dessinez un point, et choisissez l'accrochage nodal pour la sélection.
( setq pt ( getpoint"\nChoix d'un point\n"))
| Console lisp | (8536.9 5711.13 0.0) |
| AutoCAD | X = 8536.9042 Y = 5711.1315 |
Dans la Console Visual Lisp, qu'on affiche en appuyant sur la touche F6, il suffit de taper le nom de la variable pour voir ce qu'elle contient, si on veut interroger le contenu d'une variable depuis la ligne de commande d'AutoCAD il faut taper son nom en le faisant précéder d'un point d'exclamation !
Commande: !pt
(4.04497e+006 748261.0 0.0)
C'est donc bien des valeurs complètes, cette vraie valeur (complète) est stockée de manière invisible avec toutes les décimales utiles dans la mémoire affectée à la variable. On peut attribuer ce fonctionnement à une "paresse d'affichage".
Dans l'exemple suivant, chaque atome de la variable "pt" va être modifié en chaîne de caractères en système décimal avec neuf décimales.
Voir les fonctions (rtos), (car) et (cadr) si vous ne les connaissez pas encore.
Les valeurs dans l'exemple ne sont pas contractuelles et ne seront sans doute pas celles affichées chez vous lors du test (hihi)
Choix du point :
( setq pt ( getpoint"\nChoix d'un point\n"))
Extraction de l'abscisse (coordonnée X ) :
(rtos (car pt) 2 9)
renvoie : "8536.904155274"
Extraction de l'ordonnée (coordonnée Y ):
(rtos (cadr pt) 2 9)
renvoie : "5711.13150546"
Extraction de l'altitude (coordonnée Z ):
(rtos (caddr pt) 2 9)
Ou mieux encore avec une fonction anonyme et un (mapcar) , un peu plus avancé comme façon de faire mais on va en parler plus tard...
(mapcar '(lambda (x) (rtos x 2 9)) pt)
Renvoie : ("8536.904155274" "5711.13150546" "0")
Et là on s'aperçoit que ce qui est stocké est correct bien que pas forcément affiché lors de l'interrogation du contenu de la variable.
On va donc pouvoir s'en servir pour des calculs ultérieurs sans craindre une dilution de la précision par manque de renseignement de la partie décimale des nombres.
10 avril 2017