[Solved] strange rounding issue when setting Tip property of body

[uwestoehr]

I encountered a strange rounding issue which I cannot explain:

- open this simple FC file:

Tip-setting-problem-original.FCStd

(22.97 KiB) Downloaded 8 times

It is a body with 3 features. The Tip is currently at the feature "Pad".

- now save a copy of the file
- in the original file, select the body in the model tree and change in the Data tab of the combo view the Tip to "Pocket"
- in the copy file, select the feature "Pocket", right-click on it and select "Set tip"

as result both files should be in the same state. But when I compare their document.xml I see minor but strange rounding differences:

Tip-setting-problem-Document-xml-diff.txt

(3.6 KiB) Downloaded 11 times

You might say the differences are negligible but it is strange that the value 5 is not used and that one time the rounding leads to values below 5 and sometimes above 5.

I am reporting this because these differences could be part of this bug I encountered:
https://forum.freecadweb.org/viewtopic.php?f=3&t=34334

For reference, this is the diff-file of the GuiDocument.xml:

Tip-setting-problem-GuiDocument-xml-diff.txt

(24.6 KiB) Downloaded 11 times

These differences are quite big.

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15860 (Git)
Build type: Release
Branch: master
Hash: 3b708c7f84b0425076b520e1d95627b20fd75fe0
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)

[user1234]

I am not an expert but is not the important file the Document.xml ? And when you test somethig like this you should post your version from the OCCT and FreeCAD itself. The Document.xml file is in my version from FreeCAD (with a refresh of the file) OK, regardless of whether Tip is active. But from the OCCT Kernel there always rounding issues.

My version

Code: Select all

OS: Debian GNU/Linux buster/sid
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15935 (Git)
Build type: Release
Branch: master
Hash: afc44af3e9996419d457d02c9dde897f27b55341
Python version: 3.7.2+
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

Greetings
user

edit: correct typo

[uwestoehr]

I am not an expert but is not the important file the Document.xml ? And when you test somethig like this you should post your version from the OCCT and FreeCAD itself.

I don't understand. Yes, the document.xml defines the coordinates of features and I referred to it. I also posted my FC version and its libraries.

[chrisb]

Did you forget the recompute? It is not performed automatically on my Linux version while it is on MacOS.

[uwestoehr]

Did you forget the recompute? It is not performed automatically on my Linux version while it is on MacOS.

I did this by marking the body to be recomputed. The rounding issue persists. It might be negligible as I wrote, I cannot estimate this just reported it for the developers because noticed it.

[GeneFC]

I looked at both of the "diff" files.

From the second one (GuiDocument.xml) it seems that the camera angle was changed during the test. Therefore the colors changed quite a bit. The errors in the first file (Document.xml) are in the 15th and 16 decimal places.

Are you serious about calling this a "strange rounding issue"?

I see that kind of rounding variation in every model I create. However, I work in "inch" units so most of my numerical values are not integer in either inches or millimeters. If you tend to work in integer millimeters you may not see that rounding as often.

in any case, I set my default precision to 6 decimal places, and I have never, ever seen a problem from the rounding that occurs.

Gene

[uwestoehr]

The errors in the first file (Document.xml) are in the 15th and 16 decimal places.

I know and this is why I called it strange. The desired value is the integer "5", so there is no need for any rounding, not even in the 15th decimal.
And to repeat myself, if this can be neglected, fine with me, I just reported in case this might be interesting or is a hint of a potential problem.

[NormandC]

Please do not post suspected bugs here. Read the description for the forum. Are you offering code to fix the issue? No? Then it has no place here.

Read up the bug reporting guidelines in the Help forum please. It is perfectly clear: suspected bugs should be discussed in the Help forum.

EDIT: thanks to the anonymous moderator who moved the topic from the "PartDesign module development" forum to the Help forum.

[uwestoehr]

Are you offering code to fix the issue? No? Then it has no place here.

Ehm, this is a development discussion forum. So why not discuss things then? And again and again, first read what I wrote. If the rounding can be ignored, fine.

[NormandC]

Ehm, this is a development discussion forum. So why not discuss things then?

Discussing it is fine, but not in the development forum. Please read the "PartDesign module development" forum description:

FC_forum_PartDesign_Dev_01.png (16.02 KiB) Viewed 248 times

In plain text (in case the image can't load):

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!

There is a distinction between development and bug fixing. Your topic is about a bug issue, not about development. As I previously wrote:

Read up the bug reporting guidelines in the Help forum please. It is perfectly clear: suspected bugs should be discussed in the Help forum.

Bug submission guidelines

If you are unsure, discuss the problem on the forum first. Open a new topic here on the forum, in the help section

And again and again, first read what I wrote.

"Again and again"? This was the first time I replied in your topic, this is the first time you tell me to read what you wrote.

First try to post in the correct forum. I was moderator/forum admin here for some years. One of my big pet peeves was (and still is) people not posting to the correct forum. I am actually the one who added "PLEASE DO NOT POST HELP REQUESTS HERE!" to the PartDesign forum description. If you do not agree with the PartDesign forum's purpose, then open a topic about it in the Open discussion forum and see if you can reach consensus on changing its rules.