Inconsistent numeric input conversion #37327

New Issue

Willi · 2013-11-05T18:13:39+01:00

Willi commented

2013-11-05 18:13:39 +01:00

%%%--- Operating System, Graphics card ---
Win7/64, AMD HD 6850 (driver 13.9)

- Blender version with error, and version that worked ---

Blender 2.69.
Same problem in oldest 2.5 release

- Short description of error ---

Entering the same numeric value in a numeric edit box does not always lead to the same value being stored.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

In a new project (the one with the cube, you know) set the units to metric. Leave the "Scale" setting untouched (1.0 by default).
Select the cube and enter edit mode.
In 3D view, select one vertex, open the properties panel, click on the X coordinate to enter edit mode, type 0 and press enter.
Again click on the value to enter edit mode, type 0.0001 and press Enter. As this is meters if no unit is entered, Blender correctly shows "0.1 mm" afterwards.
Again click on the value to enter edit mode, type 3 and press Enter. Blender correctly shows "3 m".
Again click on the value to enter edit mode, type 0.0001 and press Enter. Blender now shows "99.89738". This is different from what is shown after entering exactly the same value at step 4. Even if floating point (in)accuracy is taken into account, when entering the same value twice, I expect the same result.

Details:
Binary format (little endian) of decimal value 0.0001

after entering it the first time: 0x17 0xB7 0xD1 0x38
after entering it the second time: 0x00 0x80 0xD1 0x38

A blend file is not attached because you have to perform the steps to see the behavior.

Problem confirmed here:
http://blenderartists.org/forum/showthread.php?316672-Entering-numeric-values%%%

%%%--- Operating System, Graphics card --- Win7/64, AMD HD 6850 (driver 13.9) - Blender version with error, and version that worked --- Blender 2.69. Same problem in oldest 2.5 release - Short description of error --- Entering the same numeric value in a numeric edit box does not always lead to the same value being stored. - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. In a new project (the one with the cube, you know) set the units to metric. Leave the "Scale" setting untouched (1.0 by default). 2. Select the cube and enter edit mode. 3. In 3D view, select one vertex, open the properties panel, click on the X coordinate to enter edit mode, type 0 and press enter. 4. Again click on the value to enter edit mode, type 0.0001 and press Enter. As this is meters if no unit is entered, Blender correctly shows "0.1 mm" afterwards. 5. Again click on the value to enter edit mode, type 3 and press Enter. Blender correctly shows "3 m". 6. Again click on the value to enter edit mode, type 0.0001 and press Enter. Blender now shows "99.89738". This is different from what is shown after entering exactly the same value at step 4. Even if floating point (in)accuracy is taken into account, when entering the same value twice, I expect the same result. Details: Binary format (little endian) of decimal value 0.0001 - after entering it the first time: 0x17 0xB7 0xD1 0x38 - after entering it the second time: 0x00 0x80 0xD1 0x38 A blend file is not attached because you have to perform the steps to see the behavior. Problem confirmed here: http://blenderartists.org/forum/showthread.php?316672-Entering-numeric-values%%%

Willi commented

2013-11-05 18:13:39 +01:00

Changed status to: 'Open'

Bastien Montagne commented

2013-11-07 18:57:38 +01:00

%%%Will try to understand what happens here.%%%

Bastien Montagne commented

2013-11-08 12:30:50 +01:00

%%%In fact, we do have a float error issue here, but the real problem was that the "µm" unit text wasn't drawing (instead of expected 0.1mm, you should have get 99.89738µm)…

Fixed in r61198, thanks for the report. :)%%%

%%%In fact, we do have a float error issue here, but the real problem was that the "µm" unit text wasn't drawing (instead of expected 0.1mm, you should have get 99.89738µm)… Fixed in r61198, thanks for the report. :)%%%

Bastien Montagne commented

2013-11-08 12:30:50 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2013-11-08 12:30:50 +01:00

Willi commented

2013-11-09 02:16:52 +01:00

%%%Thanks for the quick reply and fix. I'll check it out as soon as the built is available.

However, sorry for disagreeing, but this does not target the actual problem. Even a single precision value is capable of storing 0.0001 more precisly than as 0.00009989738. The closest values (including irrelevant decimal digits) are:

0.0000999999974737875
0.0001000000047497450

Of course, both displayed as 0.0001 as irrelevant digits are truncated during formatting.

Single precision is capable of distinguishing between 0.00009989738, 0.00009989739, ......, 0.00010000000, 0.00010000001, so there is no reason to "round" to 0.00009989738. This is even a large deviation.

Please also note that, as I've just figured out, the problem is even unrelated to the conversion from/to metric system. You can prove it this way:

Procedure #1:

switch to blender units
Enter "0"
Enter "0.0001"
Switch to metric: "0.1mm" is shown

Procedure #2:

switch to BU
Enter "0"
Enter "3"
Enter "0.0001"
Switch to metric: "99.89738 µm" is shown

This does not make sense. At the point in time when switching to metric, the previous values (zero or three) must not have an influence on what is stored and displayed now. Consequently the error is when parsing/storing a new input. In any case, the old value must just be overwritten and have no influence on the new value.

Anyway....
I'm not familiar with the source code, so it took a couple of hours to find the right location where the magic happens. In short: The problem is that we actually edit a median point, not a single vertex position. When editting is done, the difference between the old and the new median value is added to the previous value. That's not really surprising, but by becoming aware of it after looking at the source, it explains the problem. Long story short:

New value = OldValue + Difference = 3.0f - (0.0001F - 3.0f) = 0.0009989738F

This is because the difference is not exactly -2.9999 but -2.99990010261...

This computation using the differences makes sense when more than one vertex is selected, but it causes unneccessary inaccurarcy whenever only one vertex is selected. Then just storing the new value would be appropriate. Another option, when the new entry is accepted, is converting all involved values to double before the computation and convert the final result to float. Of course it will never be exactly 0.00001 but as close as possible.%%%

%%%Thanks for the quick reply and fix. I'll check it out as soon as the built is available. However, sorry for disagreeing, but this does not target the actual problem. Even a single precision value is capable of storing 0.0001 more precisly than as 0.00009989738. The closest values (including irrelevant decimal digits) are: 0.0000999999974737875 0.0001000000047497450 Of course, both displayed as 0.0001 as irrelevant digits are truncated during formatting. Single precision is capable of distinguishing between 0.00009989738, 0.00009989739, ......, 0.00010000000, 0.00010000001, so there is no reason to "round" to 0.00009989738. This is even a large deviation. Please also note that, as I've just figured out, the problem is even unrelated to the conversion from/to metric system. You can prove it this way: Procedure #1: 1. switch to blender units 2. Enter "0" 3. Enter "0.0001" 4. Switch to metric: "0.1mm" is shown Procedure #2: 1. switch to BU 2. Enter "0" 3. Enter "3" 4. Enter "0.0001" 5. Switch to metric: "99.89738 µm" is shown This does not make sense. At the point in time when switching to metric, the previous values (zero or three) must not have an influence on what is stored and displayed now. Consequently the error is when parsing/storing a new input. In any case, the old value must just be overwritten and have no influence on the new value. Anyway.... I'm not familiar with the source code, so it took a couple of hours to find the right location where the magic happens. In short: The problem is that we actually edit a _median point_, not a single vertex position. When editting is done, the difference between the old and the new median value is added to the previous value. That's not really surprising, but by becoming aware of it after looking at the source, it explains the problem. Long story short: New value = OldValue + Difference = 3.0f - (0.0001F - 3.0f) = 0.0009989738F This is because the difference is not exactly -2.9999 but -2.99990010261... This computation using the differences makes sense when more than one vertex is selected, but it causes _unneccessary_ inaccurarcy whenever only one vertex is selected. Then just storing the new value would be appropriate. Another option, when the new entry is accepted, is converting all involved values to double before the computation and convert the final result to float. Of course it will never be exactly 0.00001 but as close as possible.%%%

Willi commented

2013-11-09 02:27:30 +01:00

%%%...Or, in blender units, first enter 9999, then enter 0.1. Result is 0.09961. Considering that 0.1 is not an extremely small value, the result is not acceptable (IMO).
Then enter 0.1 again and you'll get 0.1 only because the difference to the previous value is not so big.
%%%

%%%...Or, in blender units, first enter 9999, then enter 0.1. Result is 0.09961. Considering that 0.1 is not an extremely small value, the result is not acceptable (IMO). Then enter 0.1 again and you'll get 0.1 only because the difference to the previous value is not so big. %%%

Bastien Montagne commented

2013-11-09 11:38:05 +01:00

%%%Thanks for investigating this, Armin. Committed an (obviously partial) fix in r61208. Ultimately we should probably switch to doubles, but I think there are more parts of Blender that would need that too, so that’s more like a TODO topic. ;)%%%

Willi commented

2013-11-10 16:00:26 +01:00

%%%Just tested in the latest build. It works. :) Thanks for the quick fix!

I have another closely related issue, but I'm still pondering whether or not to report it is as a (seperate) bug/inconsistency. Don't want to create unnecessary noise.%%%

%%%Just tested in the latest build. It works. :) Thanks for the quick fix! I have another closely related issue, but I'm still pondering whether or not to report it is as a (seperate) bug/inconsistency. Don't want to create unnecessary noise.%%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Inconsistent numeric input conversion #37327