Bug (-: on Linux only, once again ?)

[SerPat]

System hôte : Linux opensuse:leap:15.4 / KDE3
QCAD/CAM Version : 3.29.3.0 (3.29.3)
Date de fabrication : Jan 23 2024
Révision : 0039406
Qt Version : 5.8.0
Architecture : x86_64

(en)
I was wondering why the more versions go by, the more the inaccuracy grows... It could just be a bug. I did a copy and paste: (copy with reference in abs -48:0) from one document to another (paste in abs 0:0) and I ended up with monstrous errors. Errors that I spent my time correcting recently, so much so that I was considering returning to the "free" version, the version of which I had tested was more functional and infinitely less expensive (since the component CAM seems very very weak to me).
I am attaching the files. For DEVELOPERS: note that once this error was spotted, I wanted to keep only the copied graphic part on the source, and in this case, the error had disappeared.
You will easily find the part copied in the source file, and the line whose information is displayed.

Note: if this is a bug (-:!), I will not file a report.
Note2: I tried twice to post this on the "chat", without success. Between each attempt, BBCode asked me to log in (again) and re-displayed the page but my text had disappeared (maybe the files were downloaded)

(fr)
Je me demandais pourquoi plus les versions passent et plus l'imprécision grandit… Ce ne peut-être qu'un bug. J'ai fait un copier-coller : (copier avec référence en abs -48:0) d'un document à un autre (coller en abs 0:0) et je me retrouve avec des erreurs monstrueuses. Des erreurs que j'ai passé mon temps à corriger dernièrement, tant et si bien que j'envisageais le retour à la version "libre", dont la version que j'avais testée était plus fonctionnelle et infiniment moins chère (vu que la composante CAM me paraît très très faible).
Je joins les fichiers. Pour les DÉVELOPPEURS : notez qu'une fois cette erreur repérée, j'ai voulu ne garder sur la source que la partie graphique copiée, et dans ce cas, l'erreur avait disparu.
Vous trouverez facilement la partie copiée dans le fichier source, et la ligne dont les infos sont affichées.

Note: s'il s'agit d'un bug (-: !), je ne remplirai pas de rapport.
Note2 : j'ai essayé deux fois de poster ceci sut le "chat", sans succès. Entre chaque tentative, BBCode me demandait de me logger (à nouveau) et ré-affichait la page mais mon texte avait disparu (mais les fichiers ont été télé-chargés)

Sélection_003.bmp (702.29 KiB) Viewed 1486 times

Sélection_002.bmp (705.18 KiB) Viewed 1486 times

Démo_org.dxf

Source

(187.25 KiB) Downloaded 55 times

Démo_dst.dxf

Destination

(116.24 KiB) Downloaded 53 times

[Husky]

I did a copy and paste: (copy with reference in abs -48:0) from one document to another (paste in abs 0:0) and I ended up with monstrous errors.

It would help if you elaborate what are those monstrous errors are. The screenshots showing only that for the length value different precisions are used - other than that the values are identical except position.

[SerPat]

QCAD Community Edition

Version : 3.21.2.0 (3.21.2)
Internet : QCAD.org
Date de fabrication : Jul 9 2018
Révision : ad98624
Qt Version : 5.8.0
Architecture : x86_64

Voulant revenir au libre, je constate que le problème subsiste (même fichier source)... Mais quand j'avais essayé, système et installation était différents : que se passe-t-il avec les librairies (ou bibliothèques, à la fin, je ne sais plus, en français !) dont celle de QT ?

[SerPat]

(en)
What I don't understand is that one of the displays shows a lot of decimal places and the other doesn't,
and why, apart from the offset of -48, the error is 0.0012084. For a copy and paste, these can't be intrinsic calculation errors, right?
However, before encountering this error (copy and paste), I searched unsuccessfully for explanations on:
"Edit" menu -> "Application preferences" ->
"Modify": "Offset"
“Modify”: “Decompose”
“Modify”: “Order of connected objects”
where it is a question of tolerance.

(fr)
Ce que je ne comprends pas, c'est d'une part que l'un des affichages montre beaucoup de décimales et l'autre non,
et pourquoi, hormis le décalage de -48, l'erreur est de 0.0012084. Pour un copier-coller, il ne peut s'agir d'erreurs de calcul intrinsèques, n'est-ce-pas ?
Cependant avant de tomber sur cette erreur (de copier-coller), j'ai chercher sans succès des explications sur :
Menu "Édition" -> "Préférences de l'application" ->
"Modifier" : "Décalage"
"Modifier" : "Décomposer"
"Modifier" : "Ordre des objet connectés"
où il est question de tolérance.

[SerPat]

For the display difference, I assume it comes from the difference between "Application Settings" and "Drawing Settings".

[Husky]

Application Preferences is responsible for new drawings. Drawing Preferences is responsible for the actual loaded drawing what means there are already noticeable differences between the source and the target drawing.

Equaliz the source and target drawing regarding the precision below Drawing Preferences/Dimension setting.

Btw: Both drawings are set to the same unit?
If not keep in mind that qcad, during a paste procedere, will convert the source unit into the target unit.

[SerPat]

Both drawings are set to the same unit?

(en)
Yes, both drawings are supposed to be defined in the same unit (mm). But for you, what does the menu "Edit" -> "Application Preferences" -> "General" say: "drawing unit" for each drawing? Unfortunately, I am not an expert in reading the text contained in ".dxf" files, but I assume that this information must necessarily be there.

(fr)
Oui, les deux dessins sont censés être définis dans la même unité (mm). Mais pour vous, que dit le menu "Edition" -> "Préférences de l'application" -> "Général" : "unité de dessin" pour chaque dessin ? Malheureusement, je ne suis pas un expert dans la lecture du texte contenu dans les fichiers ".dxf", mais je suppose que cette information doit nécessairement s'y trouver.

[Husky]

Again - Application Preferences is right now for your case irrelevant.
Drawing Preferences is what counts for the reported copy/paste issue. Make sure both drawings have same settings.

[SerPat]

J'ai cru que je n'avais pas de solution (turn around). Je me suis trompé, plus d'explication éventuellement, plus tard.

[SerPat]

(en)
I just downloaded the latest trial version (3.29.4-trial). I still have the same problem. But I thought I was wrong, because oh joy, on the occasion of a second try, the new drawing was correct, hence the previous post. So: sometimes it's correct, sometimes it's not. Very embarrassing. In addition, the trial version cannot be used when you spend hours drawing!
I use this tool extensively and I don't know how to solve my problem (turn around)... So I'm really stuck. Demo_org.dxf is incorrect according to my criteria. So I wanted to "correct" it entirely and "manually", but even "copy-paste" on the same drawing causes errors. I'm giving up, at least for tonight.

(fr)
Je viens de télécharger la dernière version d'essai (3.29.4-trial). J'ai encore le même problème. Mais je pensais m'être trompé, car oh joie, à l'occasion d'un deuxième essai, le nouveau dessin était correct, d'où le post précédent. Donc : parfois c'est correct, parfois non. Très embarrassant. De plus, la version d’essai ne peut pas être utilisée lorsque vous passez des heures à dessiner !
J'utilise beaucoup cet outil et je ne sais pas comment résoudre mon problème (turn around)…
Je suis donc vraiment bloqué. Demo_org.dxf est incorrect selon mes critères. J'ai donc voulu le "corriger" entièrement et "manuellement", mais même un "copier-coller" sur un même dessin provoque des erreurs. Je jette l'éponge au moins pour ce soir.

[CVH]

SerPat:

Your differences are by design ... It is not QCAD that has introduced the 0.0012.... offsets.
I think that you need to be more precise when designing these drawings.
Many things don't line up. Exploit the most suited snapping tools.
Even the Grid would already be suitable given that the required accuracy is probably 0.10 unit.

Source: Démo_org.dxf .. handle 0x1553: Rondelle_4x7x1 .. X= -47.99879156118738166
Corresponding line on layer 'Bords_verticaux_MDF_5·5' .. handle 0x1556 .. X= -48.00000000000009237
... Delta X is 0.00120843881271071
Corresponding line on layer 'Rondelle_roulement_mobile' .. handle 0x155e .. X= -47.99999316088840828
... Delta X is 0.00120159970102662

Destination: Démo_dst.dxf .. handle 0x52: Rondelle_4x7x1 .. X= 0.0000000000001
Corresponding line on layer 'Bords_verticaux_MDF_5·5' .. handle 0x62 .. X= -0.00120843881281071
... Delta X is 0.00120843881291071
Corresponding line on layer 'Rondelle_roulement_mobile' .. handle 0x6c .. X= -0.0012015997011266
... Delta X is 0.0012015997012266

Both Deltas are fairly good matches, meaning that Démo_dst.dxf is (almost) a perfect snippet of Démo_org.dxf shifted about 48 units in X.

Almost:
Values in Floating Point double notation are as exact as can be with 15-17 significant digits disregarding the position of the decimal point.
Floating Point values have a certain amount of uncertainty, for example: One can not express 0.1 aka 1/10 in binary format.
Every manipulation of drawing entities preforms numerous calculations.
The uncertainty of the result of a mathematical expressions of two uncertainties can only grow.

But all this has nothing to do with the reported issue, it only explains why the deltas don't match exactly.
Values near 48 have a 2 digits lesser accuracy compared with values near zero to start with.
Values near 310 have a 3 digits lesser accuracy. Beyond 999 > 4, beyond 9999 > 5 and so on.
Floating Point double can not store, nor invent, more than 52 binary digits.

For the record:
I verify Math in a graphical way with QCAD and that is the reason why I have tools to retrieve values in full Floating Point notation (and beyond).

Regards,
CVH

[CVH]

Additionally I looked up your previous post on such errors (... again...):

dummy_display.dxf of post: https://www.qcad.org/rsforum/viewtopic. ... 305#p24299
Start point of that line is (-0.00000012121716964, 13.00000000000008704)
End point is (0.00000012121697068, 7.00000000000011458)
(The dimensions by Husky don't even reflect the sign in X because it is 1.2e-7 to the left and 1.2e-7 to the right)

If we do the Math then it is slanted about 0.00000024243414032 units over about 5.99999999999997246 units.
Or about 2.3150755083697394755100458775752e-6 degrees

Orientation is thus about 270.0000023150755083697394755100458775752 degrees.
Not vertical and rounded to 8 decimal places it displays as 270.00000232, with 6 decimal places as 270.000002

No magic there, no rocket science involved.
Somebody has designed this line in this way ... Floating Points is not 100% exact but these differences exceed such errors in several magnitudes.

Unless the origin of the data is a system exploiting single precision instead of double precision.
Unless there were several tens to hundreds of thousands of manipulations involved.


QCAD reads and keeps the values as they are stored in the DXF.
QCAD resources in ECMAScript and C++ libraries are optimized to keep uncertainties low when doing Math.
Low ... It can't by exact.
You can not expect that values must be altered on the fly as mentioned in that topic.
QCAD is not AI and can not interpret what you see in the drawing ...
... QCAD does not know the relationship between entities and parts made up of several entities ...
... With truncating values it won't add up anymore very quickly and what then?

Regards,
CVH

[SerPat]

(en)
Hello CHV and thank you for your posts.

My positioning needs as a user are set at +/- 5/100th. With a mantissa of more than 50 bits the precision should be around 1*10ee-15. I know that the intersection of a circle by a line probably gives real numbers as coordinates and I have no idea of the precisions rendered by transcendental functions. For a drawing in progress (before saving and especially replay), errors due to base changes normally only appear when the user enters and presents a result to the user (uncomplet, but...). I have inaccuracies of the order of a thousandth: it's really too much (and was not so much, on earlier version).

In 2022, I wrote a piece of code of around a hundred lines in C to "compact" the DXF files a little bit. To put it simply (for beginners), these files are texts and the numbers are represented in decimal (-: phew!). My specifications were simple: if a number in the file has N (N -> passed as parameter) consecutive decimal places of 0 or 9, the number is rounded. Funny idea? Probably, or excessive purism (greed)! Anyway, it works and I just went from a 204kb file to 197kb. Below is a snippet of the comparison with "diff --suppress-common-lines -y…" of these two files.
4.762499999999999 | 4.7625
9.524999999999999 | 9.525
63.50000000000001 | 63.5
9.524999999999999 | 9.525
38.09999999999999 | 38.1
88.89999999999999 | 88.9
-4.999999999999986 | -5.0
8.499999999999964 | 8.5
8.49999999999995 | 8.5
8.49999999999995 | 8.5
19.49999999999996 | 19.5
19.49999999999996 | 19.5
30.49999999999996 | 30.5
19.49999999999996 | 19.5
30.49999999999996 | 30.5
The pros at RibbonSoft GmbH will laugh, because writing a command that manipulates an ASCII text file is at beginner level!

The great thing would be if something similar was offered "online", that is to say in the application itself.

My wish is to spend less time "correcting" the drawings. This wish seems easy to implement to me: it could be with the values displayed in the "property editor" window being displayed in red (for example) under certain conditions set by the user, like the code described above. More complicated would be a button that enters the rounding into the relevant field. But already, drawing the user's attention to a suspicious field would be great. Note that this would also be an opportunity for developers (of which you seem to be one) to check if an operation was “all right”. There is food for thought in writing a "specification", but it should not be a problem for RibbonSoft pros.

If we assign 25 of the 50 mantissa bits to the display for the user (more than 7 decimal places must be displayed to "see" the imprecision), and the values stored in the files only contain 7 significant digits (rounded judiciously ), the error would be automatically corrected upon rereading (-: You can see that I have never worked developping drawing software (and numerical applications)!

To return to our subject, the operations involved are copy and paste. Calculation errors? OK, but not on additions, and that's all that a shift of 48 can imply! Also, why does QCad show me values with 7 decimal places? Why not all those which result from calculations and base changes (like your adaptations). Because it confuses the user. Since I initially believed in the quality of QCad's build, I figured I must have misjudged the Cam component of QCadCam and that it was probably due to the system bug somewhere else. Hence the system upgrade: I moved to OpenSuse Leap 15.5. Nothing happened. I wanted to delete everything related to QCad, in particular hidden configuration files: I found few and I still haven't arrived at a correct result. However, I believe that the installer should do a much more thorough cleaning before installing. My first purchase was at the beginning of 2019.

Tomorrow I install Leap 15.5+KDE3 on an SSD, install QCad Cam 3.29.3 and inform you of the result…

No one guided me to find the documentation related to
"Edit" menu -> "Application preferences" ->
"Modify": "Offset"
“Modify”: “Decompose”
“Modify”: “Order of connected objects”
where it is a question of tolerance.

Regards

(fr)
Bonjour CHV et merci pour vos posts.

Mes besoins en positionnement comme utilisateur sont fixés à +/- 5/100ème. Avec une mantisse de plus de 50 bits la précision devrait être de l'ordre de 1*10ee-15. Je sais que l'intersection d'un cercle par une droite donne probablement des nombres réels comme coordonnées et je n'ai aucune idée des précisions rendues par les fonctions transcendantales. Pour un dessin en cours (avant enregistrement et surtout relecture), les erreurs dues aux changements de base n'apparaissent normalement qu'au passage de la saisie de l'utilisateur et de la présentation d'un résultat à l'utilisateur. J'ai des imprécisions de l'ordre du millième : c'est vraiment trop.

En 2022, j'ai écrit un bout de code d'une centaine de lignes en C pour "compacter" un peu les fichiers DXF. Pour faire simple (pour les néophytes), ces fichiers sont des textes et les nombre y sont représentés en décimal (-: ouf !). Mon cahier des charges était simple : si un nombre du fichier comporte N (N -> passé en paramètre) décimales consécutives de 0 ou 9, le nombre est arrondi. Drôle d'idée ? Probablement, ou purisme (avarice) excessif ! Quoi qu'il en soit, ça fonctionne et je viens de passer d'un fichier de 204 Ko à 197 Ko. Ci-dessous, un extrait de la comparaison avec "diff --suppress-common-lines -y…" de ces deux fichiers.
4.762499999999999 | 4.7625
9.524999999999999 | 9.525
63.50000000000001 | 63.5
9.524999999999999 | 9.525
38.09999999999999 | 38.1
88.89999999999999 | 88.9
-4.999999999999986 | -5.0
8.499999999999964 | 8.5
8.49999999999995 | 8.5
8.49999999999995 | 8.5
19.49999999999996 | 19.5
19.49999999999996 | 19.5
30.49999999999996 | 30.5
19.49999999999996 | 19.5
30.49999999999996 | 30.5
Les pros de RibbonSoft GmbH vont rigoler, car écrire une commande qui manipule un fichier texte ASCII est d'un niveau débutant !

Le génial serait que quelque chose de similaire soit proposé "en ligne" c'est à dire dans l'application elle même.

Mon souhait est de passer moins de temps à "corriger" les dessins. Ce souhait me semble assez facile à implémenter : ce pourrait être avec les valeurs affichées dans la fenêtre "éditeur de propriété" le soient en rouge (par exemple) dans certaines conditions fixées par l'utilisateur, à la manière du code décrit plus haut. Plus compliquer serait un bouton qui entre l'arrondi dans le champ concerné. Mais déjà, attirer l'attention de l'utilisateur sur un champ suspect serait formidable. À noter que ce serait également l'occasion pour les développeurs (dont vous semblez faire partie) de vérifier si une opération a fait "tout bon". Il y a matière à réflexion pour écrire un "cahier des charges", mais ce ne devrait pas être un problème pour les pros de RibbonSoft.

Si on affecte 25 des 50 bits de mantisse à l'affichage pour l'utilisateur (il faut afficher plus de 7 décimales pour "voir" l'imprécision, et que les valeurs stockées dans les fichiers ne comportent que 7 chiffres significatifs (arrondi judicieusement), l'erreur serait automatiquement corrigée à la relecture (-: Vous voyez que je n'ai jamais travaillé sur un logiciel de dessin !

Pour revenir à notre sujet, Les opérations impliquées sont des copier-coller. Des erreurs de calcul ? OK, mais pas sur des additions, et c'est tout ce que peut impliquer un décalage de 48 ! De plus, pourquoi QCad m'affiche-t-il des valeurs avec 7 décimales ? Pourquoi pas toutes celles qui résultent des calculs et des changements de bases (comme vos adaptations). Comme j'ai d'abord cru à la qualité de la construction de QCad, Je me suis dit que j'avais dû mal évaluer la composante Cam de QCadCam et que c'était probablement dû au système. D'où la mise à niveau du système : je suis passé à OpenSuse Leap 15.5. Rien n'y a fait. J'ai voulu supprimer tout ce qui a trait à QCad, en particulier des fichiers de configuration cachés : j'en ai peu trouvé et je ne suis toujours pas arrivé à un résultat correct. Je crois cependant que l'installeur devrait un ménage bien plus sérieux avant d'installer. Mon premier achat date de début 2019.

Demain j'installe Leap15.5+KDE3 sur un SSD, installe QCadCam 3.29.3 et vous informe du résultat…

Personne ne m'a guidé pour trouver la documentation relative à
Menu "Édition" -> "Préférences de l'application" ->
"Modifier" : "Décalage"
"Modifier" : "Décomposer"
"Modifier" : "Ordre des objet connectés"
où il est question de tolérance.

Cordialement

[CVH]

With a mantissa of more than 50 bits the precision should be around 1*10ee-15.

A precision of 15-17 significant digits, yes, not a fixed accuracy of 1e-15.
Such an accuracy is about right for values between -1 and -0.1 and between 0.1 and 1 ...
... Not really you need to figure out 1ULP for every value.

In 2022, I wrote a piece of code of around a hundred lines in C to "compact" the DXF files a little bit

Well .... It doesn't matter .... 38.1 for example can not be stored in a double Floating Point.
It will rather be 38.099999999999998 (always even).
Things like 63.5 can be stored perfectly but here the matter is the uncertainty of the result of an expression.
If we did the Math with infinite precision then the result would probably be 63.5, in Floating Point we can only guess.

Files size reduction of 3.4% are not really the goal, DXF files can easily exceed the mega bit size.
Instead of guessing, truncating, or arbitrary rounding a value the safe side is to keep it as it was.
Otherwise you are messing with the uncertainty of the value.
All fine for values with a few decimal digits ... In CAD we usually need all 15-17 digits.
Remind that 90 degree is 1.5707963267948966192313216916398... rad

My wish is to spend less time "correcting" the drawings.

Misalignment's of 0.00000012121697068 or 0.00120843881271071 are not the result of rounding errors, of uncertainties in double notation.
That is by design ... That is a human that drew it that way.

This has nothing to do with QCAD, the installed version, updates, the CAM addon or the used number system.
All these things won't fix that.

Design your drawings with more care
I proved that the Démo_dst.dxf is probably a perfect part copied from Démo_org.dxf .
The 'Rondelle' and the associated lines do not match within over 0.00120 ... In both files.

The error existed in Démo_org.dxf , you only copied it.

Regards,
CVH

[SerPat]

(en)
I don't design my drawings carefully, of course, never!
Please help me by explaining how to display the dimensions in the edit window without those seven decimal places.

(fr)
Je ne conçois pas mes dessins avec soin, bien sûr, jamais !
S'il vous plaît, aidez-moi en expliquant comment afficher les dimensions dans la fenêtre d'édition sans ces sept décimales.