VDH-Bruno

Bonjour, En natif je ne saurais dire car je ne suis plus trop les évolutions récente sur AutoCAD, en programmation c'est faisable en "jouant" avec les réacteurs pour que le Lisp se relance à chaque fois que la cote est modifiée, au final la cote resterait toujours figée mais toujours à la bonne dimension. Cdt

Bonjour, TOTALAREA dans les Lisps de (gile) doit pouvoir faire cela à tester... https://gilecad.azurewebsites.net/Lisp.aspx Cdt

Offrir du QI, c'est possible ça? Je trouve cela bien paradoxale😉 Et c'est mon dernier mot Patrick

Perso, j'aurais préféré une conversion en valeur réelle, c'est un choix 😉

@bonuscad Merci, les grands esprits se rencontrent, j'ai eu la même réflexion, le problème et que 1/2 peut être considéré comme une valeur fractionnaire et 1 / 2 / 3 / 4 / 5 comme une énumération, et c'est la que je vais faire plaisir à @Patrick Emin . @Patrick Emin Je viens de parcourir rapidement ton article, pour moi une utilisation intéressante des IA, c'est qu'elles réussissent assez bien à contextualiser une donnée dans un texte, suffit de voir les traducteurs automatique qui ne cessent de s'alimenter et donc de progresser. Sur ce type de problème une solution efficiente serait de laisser au programmeur le traitement ce qui n'est pas compliqué en soi, et de déléguer à une AI le soin de reformater les données en fonction d'un standard compréhensible pour le traitement. (Nb: sur le retour de l'IA, en lisp 1/3 est un symbole (non une valeur numérique) et 10 un nombre entier 😉).

Re, @didier Je ne pense pas qu'il faille aller plus loin dans le traitement du problème, c'est juste à titre d'illustration car sur ce type de problème on pourra toujours trouver des exceptions et rallonger indéfiniment la liste des conditions, si on ne connait pas à l'avance le domaine d'application pour faire un traitement sur mesure. Quant à la signature, c'est une contraction en forme d'hommage à un ami enseignant d'Aïkido, dont je ne me souviens plus exactement de la formulation au mot près mais qui disait : "Dans l'action d'apprendre, on entend le mot prendre et dans prendre ne jamais oublier qu'il y a rendre" Voilà je laisse libre à chacun d'interpréter ces quelques mots🙂

Bonjour, @bonuscad Bonne fête!😄 @didier Je ne suis pas convaincu que se soit le challenge qui éveille l'intérêt des anciens du forum, mais plutôt le type de donnée à traiter qui intimide les moins expérimentés. Extraire des données d'une chaine de caractère avec un formatage qui n'est pas codifié de façon rigoureuse est de mon point de vue un problème bien complexe à traiter et donne du code bien fastidieux à écrire, si on ne maitrise pas comme @(gile) les expressions régulières qui sont de mon point de vu la panacée. Si la donnée est issue d'un tableur type Excel, nous avons un formatage parfait (libellés, nombres, unités ect...) très facilement interprétable pour un programme Si la donnée est issue d'un traitement de texte cela devient beaucoup plus compliqué à interprété, ex: 10.2 mètre cube, 10.2 m3, 10.2m3. Que doit on traiter? (12.2) ou (12.2 3). De même que considère t'on comme une valeur numérique une fraction doit elle être vu comme une valeur numérique exemple 1/3 doit donner 0.33333 ou 1 & 3 et les exemple et contre exemple peuvent être très nombreux. D'ailleurs pour illustrer le propos j'invite à tester la donnée suivante: " Volume 1/3 m3 tous les 10m²" avec la version de @(gile) et les expressions régulières... A+ Bruno

Bonjour à tous, jeunes et moins jeunes Bon visiblement c'est la réunion des moins jeunes, donc je répond à l'appel 😄 Oui vous vous doutez bien que l'intitulé du post CHALLENGE entre crochet à de suite éveillé ma curiosité et me fais sortir du bois... Je ne pense pas en ce qui concerne l'algorithme : On lit la chaîne caractère par caractère, dans le sens de lecture. Dès que le caractère est un chiffre (ou un moins (-) suivi d'un chiffre), on reconstitue le nombre à partir de caractère (ou de ces caractères) et des suivants tant que se sont des chiffres ou un point (unique). On stocke le nombre reconstitué. On reprend la lecture des caractères suivants. Effectivement à la lecture de l'énoncé, j'en suis de suite arrivé à la même conclusion, ce qui signifie que le challenge ne va porter que sur un exercice de style. Les bases étant posé, je savais déjà que je laisserai (gile) dégainer ses expressions régulières (il en est l'auteur), c'est une question d'étique personnelle pour un challenge. Voilà ceci étant fait je ne vais pas bouter mon plaisir à me dérouiller les doigts en proposant tout de même quelques lignes, sachant que l'exercice était plié et qu'il n'y aurait pas d'enjeu algorithmique, sachant également que pour des raisons de souplesses et de performance les codes proposé le seront principalement sur du traitement de liste, par contre pied j'ai tenté de proposer un traitement directement sur la chaine de caractère, en me basant sur un exemple relevé au hasard du file de discutions. Mon premier jet basé sur les expressions retourné par la fonction read pour éviter de lire caractère par caractère la chaine ce qui est couteux en lisp. (defun f (str) (cond ((null (setq r (read str))) nil) ((numberp r) (cons r (f (substr str (+ (strlen (vl-princ-to-string r)) 2))))) (T (f (substr str (+ (strlen (vl-princ-to-string r)) 2)))) ) ) Un test rapide: _$ (f "slt / 18 +36.0 &gg !") (18 36.0) Ok Puis un regard plus attentif me montre qu'il y a de la ponctuation dans l'exemple fourni, et d'expérience pour avoir déjà expérimenté cette voie je comprend de suite que les caractères '.() peuvent posé problème à la fonction read Problème facilement contournable sans alourdir le code en mettant en place une trappe pour gérer les exceptions au moyen de vl-catch-all-apply Deuxième jet: (defun f (str) (cond ((vl-catch-all-error-p (vl-catch-all-apply 'read (list str))) (f (substr str 2))) ((null (setq r (read str))) nil) ((numberp r) (cons r (f (substr str (+ (strlen (vl-princ-to-string r)) 2))))) (T (f (substr str (+ (strlen (vl-princ-to-string r)) 2)))) ) ) Un second test rapide: _$ (f "Long= 450.0 m . ) 37 ( à -5.0 m !") (450.0 37 -5.0) Puis une analyse plus attentive des différents exemples, me montre que des caractères peuvent être accolé aux nombres Ce qui implique faut complexifier les lignes de codes ou proposer une fonction auxiliaire afin de formater le texte en argument pour qu'il corresponde aux limitations du code proposé. Mais quitte à analyser la chaine autant la traiter dans le même temps et je décide de changer mon fusil d'épaule en travaillant avec des listes, les données sont plus facile à analyser et moins couteuses. Ma première intention travailler avec des appels croisées mais hélas (gile) est déjà passé par là... Qu'à cela ne tienne je passe par un accumulateur pour stoker les nombres sous forme de liste et les reconstituer à la remonté des appels de la fonction récursive simple Ma troisième proposition (defun extraireNombres (txt / foo) (defun foo (l acc) (cond ((null l) nil) ((or (< 47 (car l) 58) (and (= (car l) 45) (< 47 (cadr l) 58)) (and (= (car l) 46) acc) ) (foo (cdr l) (cons (car l) acc)) ) (acc (cons (read (vl-list->string (reverse acc))) (foo (cdr l) nil) ) ) (T (foo (cdr l) nil)) ) ) (foo (vl-string->list (strcat txt " ")) nil) ) Teste _$ (extraireNombres "Longueur = 25.4mm Largeur = 12.7mm Quantité = -42.") (25.4 12.7 -42.0) A+ Bruno

Ta solution avec grdaw est très bonne, cela offre du choix et du contenu pour qui voudrait s'inspirer et se perfectionner.

@didier , après être passé dépanné hier soir un confrère et ami sur un AutoCAD récent, maintenant je sais dire j'en ai profité/amusé pour faire quelques tests sur des variables d'environnements apparu en 2015 et 2016, j'ai identifié SELECTIONEFFECT & SELECTIONEFFECTCOLOR qui influent sur l'aspect visuel des sélections et par effet de bord sur l'aspect visuel des entités géré par la fonction lisp redraw. La première SELECTIONEFFECT paramétré sur 0 permet de retrouver l'ancien style d'affichage des sélections, paramétré sur 1 la couleur de l'aspect visuel de la surbrillance devient dépendant de SELECTIONEFFECTCOLOR. SELECTIONEFFECTCOLOR est initialement réglé sur 0, elle accepte les 255 couleurs de la table ACI, personnellement j'ai gardé un environnement de travail sur fond noir et j'ai réglé SELECTIONEFFECTCOLOR sur 3 (vert), j'ai trouvé le visuel satisfaisant. Voilà pour le retour

Bonjour Patrick, Un nouveau départ, un nouveau chalenge s'offre à toi notamment celui de La reconquête du temps libre. Plein de bonnes choses à toi pour la suite. Bruno

@Luna oui je te comprend, tu n'es pas la seule à connaitre cette problématique, pour te rassurer j'ai moi même sous le coude quelques lignes de code écrite par (gile) ici datant de 2013, un algorithme que j'ai échoué à implémenter, pour lequel j'aimerais prendre le temps nécessaire en recherche afin de mis consacrer sérieusement (chose que je n'ai toujours pas pris la peine de faire), un jour peut être ou dans une autre vie... 😅 A+ Bruno

Bonjour @Luna Je passais dans le coin, donc pour répondre à ton interrogation et pour l'avoir fait pas le passé (cela reste à tester sur des autocad récent) il est tout à fait possible de créer une formule avec une valeur de champ sur une entité cotation mais seulement par programmation, bien que cela ne soit pas possible manuellement, car en mode édition les propriétés de l'entité ne sont pas accessible aux valeurs de champs. Ci-dessous un lien sur ce forum ou tu trouvera un exemple de code qui permet de faire cela, si des fois cela peut servir un jour. https://cadxp.com/topic/48507-arrondir-cotes-%C3%A0-la-valeur-sup%C3%A9rieur/?do=findComment&comment=290565 A+ Bruno

@didier pour avoir écrit de nombreuses routines avec la fonction redraw, sur des anciennes version l'aspect visuel était très bien géré, il est vrai que pour ce que j'en ai vu sur les versions récentes c'est plus ça, après est ce que Autodesk aurait introduit de nouvelles variables pour y remédié je ne saurais dire.... En tout cas sur le clone d'Autocad (en version 15) qu'il m'arrive encore d'utiliser au travail cela passe encore très bien.

Bonjour, Oui c'était l'idée. A+ Bruno