Imprécision

[dfbiagio]

Bonjour à tous,

Ce n'est pas la première fois que j'ai ce type de problème.

Comme on peut le voir sur ma capture d'écran, j'ai un voile béton qui fait 450x25 soit une section de  11250 cm², mais on peut remarquer dans la fenêtre de propriété, il indique une aire de 11176,51773584 soit une erreur de 73,48227 cm². J'estime que c'est beaucoup. Quelqu'un peut dire comment ça se fait. Merci d'avance

COUPE BB.dwg

[didier]

Bonjour

Tel que c'est expliqué, c'est pour le moins incongru, je ne pense pas que ce soit possible.
Il faudrait vérifier les limites de la hachure ou si la polyligne a vraiment des points aux coordonnées exactes

Ce serait bien de pouvoir vérifier dans le fichier en le déposant sur le site pour vérifier ce que je viens de dire et assurer la précision des valeurs données par le logiciel.

Amicalement

 

[dfbiagio]

Comment faire pour déposer le fichier sur le site?

Merci

[Aleck_Ultimate]

2 minutes ago, dfbiagio said:

Comment faire pour déposer le fichier sur le site?

Soit tu le glisse jusqu'à la zone de texte quant tu écrit ou modifie ton message, soit tu clic sur le lien "choose files" en dessous de ta zone de texte.

[didier]

Bonjour

Je pense que vous avez mal regardé avant de poser la question...

En bas de la fenêtre de rédaction de message il y a un joli petit trombone qui attend qu'on dépose un fichier dessus
Merci de faire un extrait du dessin, on a besoin de la zone problématique pas TOUT le fichier.

Amicalement

[dfbiagio]

Ca va, j'ai vu.

Et ça, c'est dû au fait que lorsque je fais un zoom trop près pour ajuster mes lignes, elles disparaissent. J'ai déjà mis à jour ma carte graphique, réglé l'accélération matériel, mais rien n'y fait.

Désolé.

[Tsuki]

Ton voile ne fait pas 25 mais 24.67341216, donc... les surfaces de ta polyligne ou hachure sont bonnes

[didier]

Bonjour

Tout est en ordre, c'est parfait

Il est utile de forcer le nombre de décimales quand on est face à ce genre de souci et chercher l'erreur "chez soi"
Franchement une "erreur" de calcul de superficie eût été un scoop mondial s'il avait été avéré.
Il est des cas où la superficie n'est pas affichée, car sujette à caution, mais je n'ai jamais vu un affichage "faux"

Amicalement

[dfbiagio]

Dans le fichier ci-joint, j'ai un mur qui fait 415.5x21.4, j'ai donc une aire de 8891.7 cm², si tu cliques sur l'hachure ou sur la polyligne et tu regardes dans les propriétés, on a 8891.69999996. La différence n'est pas énorme mais...

Quand tu fais un copier coller du mur dans un autre fichier, cette imprécision disparaît 🙃. Étonnant non !!

Bonne journée

02-ETAGE 0 - V1.dwg

[Minocia]

Bonjour, dans ton fichier 02-étage, en multipliant par 10 le côté faisant a priori 415.5 on obtient : 4154.999 999 98. Le copier dans un autre dessin ne change rien pour moi. Mais j'avoue ne pas savoir comment autocad gère la précision au-delà de 8 chiffres après la virgule.

Et dans ton fichier coupe BB, ton voile fait 25.00 en bas et 24.67 en haut → le côté gauche n'est pas vertical.

 

cordialement

[dfbiagio]

 

Minocia,

Effectivement, tu as raison, mais normalement, quand tu fais une échelle de 10, tu devrais obtenir 4155,00 et pas 4154,999 999 98 . Pour la coupe BB, c'est résolu, merci qd même.

Bon après-midi

[didier]

Bonjour dfbiago

Les coordonnées n'ont pas de valeurs trop grandes, mais ramener les objets vers le point 0,0 devrait augmenter les chances d'avoir la bonne valeur de décimales.
Je constate ce que tu dis, mais si à côté je dessine un rectangle (commande rectangle) avec les mêmes dimensions entrées au clavier j'obtiens la bonne superficie de la polyligne et si je la hachure il en est de même, c'est correct pour la superficie hachurée.

Donc il semblerait que ce soit le dessin proposé qui est entaché d'erreur, vérification faite je trouve (via lisp)

Le dessin numérique exige une rigueur accrue comparé au dessin manuel qui se "contente" de ce qui est écrit, le numérique "trimballe" avec lui des décimales pas toujours observables.

Un grand côté de 415.4999999981606, un autre de  416.0507300780559
Le petit, quant à lui est de 21.39999999999964 et l'autre de 21.40000000000055

Je ne connais pas ta méthode de dessin des entités, est-ce une formule de calcul ou un accrochage sur des points ou encore autre chose, toujours est-il que les coordonnées ne donnent pas les distances attendues, à une décimale éloignée certes mais pas la bonne en réalité.

Il est, par ailleurs, possible que les valeurs binaires ne soient pas parfaitement traduites en nombres réels, le sujet a été déjà discuté ici.

Amicalement

[dfbiagio]

Bonjour Didier,

je comprends très bien ce que tu expliques, mais à partir du moment ou je vérifie mes points et que j'obtiens:

Commande: ID Spécifiez un point:  X = 383.50000000     Y = 2644.50000000     Z = 0.00000000

Commande:
ID
Spécifiez un point:  X = 383.50000000     Y = 2623.10000000     Z = 0.00000000

Commande:
ID
Spécifiez un point:  X = 799.00000000     Y = 2644.50000000     Z = 0.00000000

Commande:
ID
Spécifiez un point:  X = 799.00000000     Y = 2623.10000000     Z = 0.00000000

même quand j'utilise ceci:

Commande: (setq a (getpoint))
(383.5 2644.5 0.0)

Commande: (setq b (getpoint))
(799.0 2644.5 0.0)

J'espère que tu es d'accord avec moi que, ce n'est quand même pas logique.  Ce qui est fou, c'est quand tu fais un copier et coller avec les coordonnées d'origines de ce mur ces imprécisions disparaissent 🙄.

Alors, quand je fais une extraction de données, j'aimerai bcq avoir 8891,7 et pas 8891,69999996. Dans mon exemple, je n'ai pris qu'un mur, mais j'en ai plusieurs comme ça 🤕

Encore merci pour votre aide.

 

[Tsuki]

Les valeurs retournée en lisp sont arrondies à l'affichage mais contiennent bien les bonnes valeurs.

Pour t'en convaincre; mesure ta poutre avec la première fois ceci en t'accrochant aux extrémités:

(getdist (getpoint "\n1er point : ") "\n2eme point : ")

puis renouvelle l'opération avec cette ligne avec les mêmes points d'accroches

(rtos (getdist (getpoint "\n1er point : ") "\n2eme point : ") 2 16)

Tu verras la différence

[didier]

Merci Tsuki (toujours pas réglé le pseudo ?)

C'est ce que j'aurais répondu si j'avais vu la question à temps.
C'est d'ailleurs ce que j'ai écrit, mais qui n'a pas convaincu dfbiago

C'est pour ça que j'ai demandé COMMENT ont été dessinées les entités, copier-coller avec échelle ou autre ...
Si c'est dessiné avec des valeurs tapées au clavier, c'est propre.

Amicalement

 

[dfbiagio]

Convaincu, je le suis, mais ça ne m'arrange pas.

J'ai fait un rectangle premier point au coin de la colonne et le second avec coordonnées tapées au clavier type @x,y.

Bonne fin de journée

[didier]

Bonjour

Je ne comprends pas,
C'est avec la commande rectangle et une réponse en coordonnées cartésiennes relatives que cette géométrie se retrouve avec des décimales qui entachent le calcul ?

Je ne pense pas que ce soit possible, c'est pourquoi je dis que je ne comprends pas

Merci de clarifier

Amicalement

[Tsuki]

1 hour ago, dfbiagio said:

Convaincu, je le suis, mais ça ne m'arrange pas.

J'ai fait un rectangle premier point au coin de la colonne et le second avec coordonnées tapées au clavier type @x,y.

Bonne fin de journée

L'utilisation de @x,y est une bonne chose mais il faut veiller à ce que les accroches objets ne soient pas actif à ce moment là car si un objet se trouve a proximité du point @x,y il sera pris en considération et appliquera le mode déclaré (ext, mil, cen etc...)

Au clavier il vaut mieux inactiver l'accroche objet et forcer ponctuellement celui-ci si besoin pour le point voulu.

La variable APERTURE (taille de la cible) si elle grande peut créer des surprises avec OSMODE actif et différent de zéro.

[didier]

Bonjour

Assurément je confirme de ne pas trop se servir des accrochages mémorisés (OSMODE)
En particulier lors de dessin sur des entités susceptibles d'être en 3D ou avec une valeur d'élévation, c'est dramatique dans ce cas, on ne trouve plus les intersections et les distances sont fausses.

Je me permets de rappeler que ce qui est tapé au clavier est prioritaire si toutefois c'est précisé dans les Options :

Exemples avec la commande LIGNE

Si je suis en "osmode" à 1 (extrémité) ET accrochage actif, je dessine en loupant une extrémité et que je clique gauche, AutoCAD va commencer la ligne au curseur
Si je suis en "osmode" à 0 (rien) OU accrochage inactif, je dessine en loupant une extrémité et que je clique gauche, AutoCAD va m'avertir qu'il n'a pas trouvé d'extrémité et ne rien faire, c'est bien plus sécurisant.
C'est surtout vrai suivant les hauteurs de ZOOM.

Pour des coordonnées relatives (ou absolues) entrées au clavier, si l'option de l'image est cochée il n'y aura pas de problèmes d'accrochage intempestif.

Bon dessin à tous en respectant les règles de base...

Amicalement

[dfbiagio]

Encore merci pour cette précision. 

Pour info, je viens de faire un test, lorsque je dessine une droite horizontale, je fais un offset de 21.4, et quand je mesure avec (rtos (getdist (getpoint "\n1er point : ") "\n2eme point : ") 2 16) j'obtiens :

1er point :
2eme point : "21.40000000000009"

et là C'EST PAS NORMAL, d'où vient ce 0000000000009 ?

J'ai essayé la même chose dans un nouveau fichier et là j'obtiens "21.39999999999998"

Enfin...

Bonne journée

[didier]

Bonjour

Comme je disais, le sujet a été amplement évoqué à maintes reprises, ce n'est pas AutoCAD le souci, on trouve les mêmes "erreurs" dans Excel (entre autres)
il s'agit "d'imprécision" due à l'utilisation de la précision en virgule flottante.

J'ai communément admis de me "contenter" de huit décimales, du moins dans les petites valeurs, quand les coordonnées passent en millions (Lambert, Mercator...) cette "tolérance" baisse

Cet article WIKI l'explicite

Essaie cette soustraction : 45256 moins 45256.28 tu obtiens  -0.28 et c'est parfait
Regardons de plus près :

(rtos (- 45256 45256.28) 2 8) ;;; RENVOIE "-0.28000000"
(rtos (- 45256 45256.28) 2 10);;; RENVOIE "-0.28000000"
(rtos (- 45256 45256.28) 2 12);;; RENVOIE "-0.279999999999"

Surprise !!!

Un bon conseil : pour faire des tests d'égalité ou de comparaison ---> Tronquer les valeurs...

Amicalement
 

[dfbiagio]

Merci

👍