unit mismatch error for dimensions

[uwestoehr]

By the way, there is also another issue with the dimensioning: when you change in the TD preferences to show/hide the unit, the page needs to be recomputed. This is however not done until you click on the page in the model tree.

[chrisb]

I can set many decimals in advance but they only have an effect for new dimensions:
FreeCAD_TY0X9nU4qe.png

This is indeed at least an unpleasant surprise; especially because the TechDraw decimals are not marked as presets in the preferences dialog.

This is a no-go for real life because it is a loss of information. The dimensions must take care to automatically extend the precision when it is not sufficient, at least in my opinion.

This is a rather uncommon opinion. While the automated extension is widely used for the number of places before the decimal separator, most applications make cut for the decimals after it, due to the limited precision of number representations. As a prominent example may serve Excel, which is widely used for calculations.

A related question may be what you call "sufficient". Only removing trailing spaces won't do. Think of modeling a house, and you divide 10m by 3, do you really want to see in your TechDraw document something like 3333,32999999999993mm? Probably not, so you may want to limit the number of decimals shown. And that is precisely what the configurable number of decimals does.

If we are talking about removing trailing zeros, then it is a different game, but for that there are different formats, such as %.3g.

[uwestoehr]

do you really want to see in your TechDraw document something like 3333,32999999999993mm?

What do you do as a human?: You change the precision only of the dimension that shows you "0.000" (and of course only of that), you try 4 decimals or 5 until have it. And this is what should be done automatically and what I will try to implement.

[aapo]

This is a no-go for real life because it is a loss of information. The dimensions must take care to automatically extend the precision when it is not sufficient, at least in my opinion.

Agreed. The workaround seems to work for me (i.e. manually increasing the number of decimals), but there should not be a need for this workaround in the first place! Definitely should be fixed.

But OK, let's do this step by step. Step one will be my PR that it does not introduce new issues, then I will sort out the remaining ones like I did for the hole dialog. Give me some time.

Thanks for doing this. It's a good plan to 1st fix the PR to work with Imperial etc units, looking forward to it! It'd be even better to fix the above precision bugs/issues later!

[aapo]

This is a rather uncommon opinion. While the automated extension is widely used for the number of places before the decimal separator, most applications make cut for the decimals after it, due to the limited precision of number representations. As a prominent example may serve Excel, which is widely used for calculations.

A related question may be what you call "sufficient". Only removing trailing spaces won't do. Think of modeling a house, and you divide 10m by 3, do you really want to see in your TechDraw document something like 3333,32999999999993mm? Probably not, so you may want to limit the number of decimals shown. And that is precisely what the configurable number of decimals does.

If we are talking about removing trailing zeros, then it is a different game, but for that there are different formats, such as %.3g.

The problem here is a little bit different, at least how I see it. I'll give an example based on the test file: There is a distance of 50 µm, which is about 0.000164 feet, when converted to my preferred "%.3g" decimal format. However, if the general unit preferences decimal is set to "2", then what happens to at least on my machine, is a bit strange: First, 50 µm is converted to feet -> 0.000164 ft, *then* it will be truncated to 2 decimals -> 0.00 ft, and only after that it'll be converted to "%.3g", which gives zero ft ("0 ft"). I can work around this by setting the general decimals to "8", so that it cuts only after 8 decimals after the decimal dot, and some precision is left for "%.3g" to work.

But it doesn't make any sense whatsoever to do the intermediate cutting of the decimals, if the end result will be formatted to "%.3g" (i.e. 3 *significant* numbers and whatever many zeros there are). I think what would make sense here is to use a system where the numbers are formatted only once, but probably due to historical reasons TD has this "convert and truncate and truncate again" abomination of a number system

[chrisb]

You are both right. The truncation should take place only once and as late as possible before displaying it.

[aapo]

You are both right. The truncation should take place only once and as late as possible before displaying it.

Yes. Luckily, it seems that uwestoehr has plans to fix that, too, after he has extended his original pull request for the unit mismatch problem to correctly work with non-metric units. I'll try to help by participating in the review of his pull request(s) when they are ready; but unfortunately only if if I'll happen to have time from my work and Christmas preparations. Let's hope for the best!

EDIT: As an extra note, what makes it difficult to fix the internal precision problem, is the fact that we have quite a lot of legacy baggage. I mean, most of the existing TechDraw drawings have number formats like "%g" or "%f", so if the legacy decimal cutting is removed, these old drawings will print long strings of decimals for many of the dimensions, which is clearly not acceptable, as you pointed out. Still, cutting the decimals before the final formatting is also clearly wrong; and there are at least two such settings in the Preferences: "General -> Units -> Number of Decimals" and "TechDraw -> Dimensions -> Alternate Decimals". Optimally, TechDraw would not need or should not respect neither of them, because there is a Preferences setting and per-dimension settings for the number format, which could be set to e.g. "%.2g" by default for 2 numbers after decimal point. That way, the full precision of the data could be kept until the very last point of the conversion. Unfortunately, a lot of legacy documents have "%g" and this intermediate decimal-cutting game, which works well for mm unit, but breaks down horribly for more special use cases. So, it's largely a question of either breaking the legacy documents or these odd special cases. Maybe detecting if the number format is "%g" and then doing the legacy decimal cutting; and otherwise using the full precision. But that'd be a bit of a hack.

[uwestoehr]

I updated the PR: https://github.com/FreeCAD/FreeCAD/pull/4094
Now it fixes also B and F and introduces no issues to any scheme

B:

Imperial-Civil with PR

Imperial-Civil-PR.png (11.08 KiB) Viewed 1183 times

Imperial-Civil units with PR

Imperial-Civil-units-PR.png (11.17 KiB) Viewed 1183 times

F:

Imperial-Decimal with PR

Imperial-Decimal-PR.png (10.55 KiB) Viewed 1183 times

Imperial-Decimal units with PR

Imperial-Decimal-units-PR.png (10.78 KiB) Viewed 1183 times

The PR also fixes the issue that you could get values like "0.00". Now as many decimals will be used so that the error between the raw and the displayed value is < 10%. That is cool, because e.g. 0.500 mm are 0.0016 ft. If you set now 3 decimals, you would get 0.002 -> 25% error. Therefore now 4 decimals will be used automatically.


Issue C (Building-US) must be fixed with another PR because the problem is thereby that Base::Quantity::getUserString() does not return a string with a unit. (it is unitless) So the bug is not in TD but somewhere in Base.

[aapo]

I realized that after your PR the "%g" format specifier does not leave out the zeros after decimal dot any more. For example, 50 would be printed as "50.00", if two decimals are selected with format specifier "%g". It used to print as "50". Although "50.00" seems to be the standard-compliant and proper way to do it nowadays, I think some people might want to do drafting the old way, and there's no convenient formatting option for them at the moment. I think there might have even been an old drafting standard (pre '94?) demanding that kind of formatting, but it's probably not in use any more.

https://www.eng-tips.com/viewthread.cfm?qid=45759

[uwestoehr]

I realized that after your PR the "%g" format specifier does not leave out the zeros after decimal dot any more. For example, 50 would be printed as "50.00"

As stated already in GitHub, that is the compromise you agreed to:
- "%g" means the number of decimals is not limited, you can also end up with an exponential output like "1e4".
- in older versions of TD "%g" was used as default but its output was always decimal and with limited number of decimals, so not really "%g". With my patch, "%g" worked as it should but existing drawings made with older TD versions were then displayed with more decimals as before
- so the compromise was to override "%g" by "%.xf" if the option to use the global number of decimals is used. x is then the number of global decimals.

So you have now 2 options for your existing drawings that use "%g":
A. You use the option to se the global decimals, then you get all dimensions with the specified decimals
B. you don't use this option and get real "%g" behavior (each dimensions can have different amount of decimals)

https://www.eng-tips.com/viewthread.cfm?qid=45759

What do the ISO norms say?
However, how will you achieve this? Just "%g" is not sufficient because this leads by default to up to 5 decimals if the dimension is a result of a calculation. But the amount of decimals also defines the precision. For example a value of "6.9282 mm" would imply you can mill/print/mould the part with a precision of 0.1 micron. I haven't read the ISO norm yet (cannot find the right one) but this seems to be not correct.