[Résolu] > et <

[bonuscad]

Bonjour, En phase de test d'un code qui ne fonctionne pas bien, je viens de me rendre compte d'un truc (qui fait partie du B.A.BA)

 (> nil -1) nil (> nil 0) nil (> nil 1) nil 

Sur cela pas lézard cela me semble tout à fait logique..., mais pour

 (< nil -1) T (< nil 0) T (< nil 1) T 

Là je ne comprends plus ?!?! Je m'attendais à un résultat identique que pour > (supérieur) Rien/Vide ne peut être inférieur à 1 0 ou -1 ... PS: Identique avec >= et <=

[Tramber]

Ah ouais marrant.

Pas si choquant que du vide soit inférieur à zéro (ce qui n'est pas rien :P )

B)

[bryce]

Pareil que Tramber, pour moi "rien/le néant" est forcément inférieur à "quelque chose". <_<

[bonuscad]

"rien/le néant" est forcément inférieur à "quelque chose".

 

Admettons,...

 

Comment tu ferais ce test alors? Sachant que le nil est un retour possible d'évaluation (1ère expression).

 

(> (vlax-curve-getDistAtPoint objet point) (vlax-curve-getDistAtPoint objet (vlax-curve-getEndPoint objet)))
(< (vlax-curve-getDistAtPoint objet point) (vlax-curve-getDistAtPoint objet (vlax-curve-getStartPoint objet)))

 

NB: Le point existe toujours, mais n'appartient pas forcément à l'objet traité.

[(gile)]

Admettons,...

 

Comment tu ferais ce test alors? Sachant que le nil est un retour possible d'évaluation (1ère expression).

 

(> (vlax-curve-getDistAtPoint objet point) (vlax-curve-getDistAtPoint objet (vlax-curve-getEndPoint objet)))
(< (vlax-curve-getDistAtPoint objet point) (vlax-curve-getDistAtPoint objet (vlax-curve-getStartPoint objet)))

 

NB: Le point existe toujours, mais n'appartient pas forcément à l'objet traité.

 

(and
 (setq dist (vlax-curve-getDistAtPoint objet point))
 (> dist (vlax-curve-getDistAtPoint objet (vlax-curve-getEndPoint objet)))
)

[VDH-Bruno]

Salut bonuscad

 

Lorsque j’ai commencé à m’intéresser au lisp, j’ai également buté sur ce que tu viens d’écrire, pour m’en sortir, j’ai traduit nil par (), puis j’ai lu littéralement ensemble vide en lieu et place de nil.

 

Ce qui revient à dire que l’ensemble vide ne peut être supérieur à une valeur numérique,

(> () -1e99); nil
(> () 0); nil
(> () -1e99); nil

 

Et donc qu’il est inférieur à toutes valeurs numériques

(< () -1e99); T
(< () 0); T
(< () -1e99); T

 

Je ne sais pas si cette explication et très orthodoxe, mais elle m’a permis de surmonter cette difficulté, pour résumer si il s’agit de liste, je pense nil, si il s’agit de nombre je pense aux ensembles mathématiques.

 

Voilà mon explication si cela peut faire avancer la discussion.

A+

[bonuscad]

Et oui le (and) tout simplement, à part que ça rajoute encore une condition pour un test si simple.

Ce truc m'a empêcher de voir l'évidence, je fatigue...

 

En résumé:

(> nil T) nil (rien/vide ne peut être supérieur à vrai)

(< nil T) T (par contre rien/vide peut être inférieur à vrai)

 

Vu comme ça (sans nombre finis), cela passe mieux ;)

[(gile)]

à part que ça rajoute encore une condition pour un test si simple.

Oui mais ça évalue si le point est bien sur la courbe, ce qui n'est pas négligeable.

[VDH-Bruno]

En résumé:

(> nil T) nil (rien/vide ne peut être supérieur à vrai)

(< nil T) T (par contre rien/vide peut être inférieur à vrai)

 

Oui mais attention T ne peut être utilisé comme nil, car il symbolise seulement le vrai et pas une valeur définit..

(< T 1); erreur: type d'argument de comparaison incorrect: T 1

 

Alors que nil et magnifique il symbolise le néant en toute chose… (liste, atom, boléen(faux), ensemble vide)

 

Cette discution me rappel une de mes premieres lectures sur le forum débutant, qui m’a tenu éveillé presque toute la nuit…

http://cadxp.com/index.php?/topic/1814-nil/

 

Amicalement

[zebulon_]

tout cela me rappelle Raymond Devos lorsqu'il explique que trois fois rien, c'est déjà quelque chose parce qu'il y a encore moins que rien