Math nodes output incorrect results. Unstable calculation #95164

New Issue

Vladimir · 2022-01-23T22:40:09+01:00

Vladimir commented

2022-01-23 22:40:09 +01:00

System Information
Operating system: Linux-5.16.2-1-MANJARO-x86_64-with-glibc2.33 64 Bits
Graphics card: Mesa Intel(R) HD Graphics 4600 (HSW GT2) Intel 4.6 (Core Profile) Mesa 21.3.4

Blender Version
Broken: version: 3.1.0 Alpha, branch: makepkg (modified), commit date: 2022-01-22 08:57, hash: dde997086c
Worked: (newest version of Blender that worked as expected)

Short description of error

When I try divide a value to another value in Math.Divide it lets an unstable result. Floating Inexact calculation result with integer values.
For example: 100/10=10 but 600/60 != 10 Why!?

Exact steps for others to reproduce the error

Download example file and play with Math.Divide

math-divide.blend

**System Information** Operating system: Linux-5.16.2-1-MANJARO-x86_64-with-glibc2.33 64 Bits Graphics card: Mesa Intel(R) HD Graphics 4600 (HSW GT2) Intel 4.6 (Core Profile) Mesa 21.3.4 **Blender Version** Broken: version: 3.1.0 Alpha, branch: makepkg (modified), commit date: 2022-01-22 08:57, hash: `dde997086c` Worked: (newest version of Blender that worked as expected) **Short description of error** When I try divide a value to another value in Math.Divide it lets an unstable result. Floating Inexact calculation result with integer values. For example: 100/10=10 but 600/60 != 10 **Why!?** ![Screenshot_20220124_002225.png](https://archive.blender.org/developer/F12819704/Screenshot_20220124_002225.png) ![Screenshot_20220124_002456.png](https://archive.blender.org/developer/F12819706/Screenshot_20220124_002456.png) **Exact steps for others to reproduce the error** Download example file and play with Math.Divide [math-divide.blend](https://archive.blender.org/developer/F12819714/math-divide.blend)

Vladimir commented

2022-01-23 22:40:09 +01:00

Added subscriber: @Wovchick

Vladimir commented

2022-01-23 23:02:17 +01:00

In Python for example always result equals 10:

a = 100.0
b = 10.0
a/b

10.0

a = 600.0
b = 60.0
a/b

10.0

In Python for example always result equals 10: ``` a = 100.0 b = 10.0 a/b 10.0 ``` ``` a = 600.0 b = 60.0 a/b 10.0 ```

Charlie Jolly commented

2022-01-24 00:41:52 +01:00

Added subscriber: @CharlieJolly

Pratik Borhade commented

2022-01-24 02:21:11 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Pratik Borhade commented

2022-01-24 02:21:16 +01:00

Added subscriber: @PratikPB2123

Vladimir commented

2022-01-24 02:43:33 +01:00

It Interesting. The problem happens only when used EEVEE render but when used Cycles, Math Node calculate correct!

2022-01-24_04-37-56.mov

It Interesting. The problem happens only when used EEVEE render but when used Cycles, Math Node calculate correct! [2022-01-24_04-37-56.mov](https://archive.blender.org/developer/F12820163/2022-01-24_04-37-56.mov)

Jesse Yurkovich commented

2022-01-24 02:55:22 +01:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2022-01-24 02:55:23 +01:00

I'm actually not able to reproduce this issue. Since this only occurs with Eevee for you, it's most likely some sort of OpenGL quirk -- maybe Mesa related, maybe Intel hardware related, maybe our usage of the API. Unsure who's really at fault though.

@PratikPB2123 Are you also on intel?

Here's a few examples from my system:
Operating system: Windows-10-10.0.19042-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.39

100/10	600/60	1000/100

110/11	50/5	130/13

I'm actually not able to reproduce this issue. Since this only occurs with Eevee for you, it's most likely some sort of OpenGL quirk -- maybe Mesa related, maybe Intel hardware related, maybe our usage of the API. Unsure who's really at fault though. @PratikPB2123 Are you also on intel? Here's a few examples from my system: Operating system: Windows-10-10.0.19042-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.39 | 100/10 | 600/60 | 1000/100 | | -- | -- | -- | | ![100-10.png](https://archive.blender.org/developer/F12820169/100-10.png) | ![600-60.png](https://archive.blender.org/developer/F12820171/600-60.png) | ![1000-100.png](https://archive.blender.org/developer/F12820173/1000-100.png) | | 110/11 | 50/5 | 130/13 | | -- | -- | -- | | ![110-11.png](https://archive.blender.org/developer/F12820175/110-11.png) | ![50-5.png](https://archive.blender.org/developer/F12820177/50-5.png) | ![130-13.png](https://archive.blender.org/developer/F12820179/130-13.png) |

Marco Hoo commented

2022-01-24 03:38:54 +01:00

Added subscriber: @MarcoHoo-3

Marco Hoo commented

2022-01-24 03:38:54 +01:00

Does the input area collapse your decimal places?

Does the input area collapse your decimal places? ![QQ截图20220124103605.png](https://archive.blender.org/developer/F12820245/QQ截图20220124103605.png) ![QQ截图20220124103552.png](https://archive.blender.org/developer/F12820247/QQ截图20220124103552.png)

Pratik Borhade commented

2022-01-24 03:42:29 +01:00

Are you also on intel?

No

100/10	600/60

Operating system : Windows-10-10.0.18362-SP0 64 Bits
Graphics card : AMD Radeon(TM) 535 ATI Technologies .```

> Are you also on intel? No | 100/10 | 600/60 | | -- | -- | | ![image.png](https://archive.blender.org/developer/F12820255/image.png) | ![image.png](https://archive.blender.org/developer/F12820251/image.png) | ```System information: Operating system : Windows-10-10.0.18362-SP0 64 Bits Graphics card : AMD Radeon(TM) 535 ATI Technologies .```

Jesse Yurkovich commented

2022-01-24 03:50:47 +01:00

Weird... ok, my older AMD system also shows the problem (Cycles remains correct though). Alright, let's tag Eevee and Viewport still since it's most likely something related to OpenGL since Cycles is ok.

Vladimir commented

2022-01-24 03:57:07 +01:00

This comment was removed by @Wovchick

*This comment was removed by @Wovchick*

Marco Hoo commented

2022-01-24 04:00:32 +01:00

I can reproduce this issue using "Greater than" operator.
I guess system give us like 10.0000001 or 9.9999999 (long decimal places that we can't see) when calculating "divide" . If we round the anwser up ro down, we can get the exact number.
bandicam 2022-01-24 10-57-15-912.mp4

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.09

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-23 00:09, hash: 5c4a5fd40d

I can reproduce this issue using "Greater than" operator. I guess system give us like 10.0000001 or 9.9999999 (long decimal places that we can't see) when calculating "divide" . If we round the anwser up ro down, we can get the exact number. [bandicam 2022-01-24 10-57-15-912.mp4](https://archive.blender.org/developer/F12820283/bandicam_2022-01-24_10-57-15-912.mp4) **System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3070 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.09 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-23 00:09, hash: `5c4a5fd40d`

Vladimir commented

2022-01-24 04:40:41 +01:00

This comment was removed by @Wovchick

*This comment was removed by @Wovchick*

Vladimir commented

2022-01-24 04:43:43 +01:00

P.S. My previous video was of low quality. I'm Sorry

2022-01-24_06-37-38.mov

P.S. My previous video was of low quality. I'm Sorry [2022-01-24_06-37-38.mov](https://archive.blender.org/developer/F12820344/2022-01-24_06-37-38.mov)

Marco Hoo commented

2022-01-24 07:54:54 +01:00

There is something that we must pay attention to.
Use custom properties and driver to see more detail:
When we input a number by typing on the keyboard, or, if we adjust the number though the increase and decrease button on the node, we may get the offset value like 10.0000001 most of the time (long decimal places that we can't see, again). And that may probably destroy our nodebased calculation.
bandicam 2022-01-24 14-58-07-476.mp4

There is something that we must pay attention to. Use custom properties and driver to see more detail: When we input a number by typing on the keyboard, or, if we adjust the number though the increase and decrease button on the node, we may get the offset value like 10.0000001 most of the time (long decimal places that we can't see, again). And that may probably destroy our nodebased calculation. [bandicam 2022-01-24 14-58-07-476.mp4](https://archive.blender.org/developer/F12820560/bandicam_2022-01-24_14-58-07-476.mp4)

Marco Hoo commented

2022-01-24 09:17:16 +01:00

Useful information below.
These two video tells us the reason why we can't get the exact result. When we input 60, that's not the exact 60 to system. It's 60.00000XXXX to system, maybe.
bandicam 2022-01-24 16-07-38-316.mp4
bandicam 2022-01-24 16-15-09-012.mp4

Useful information below. These two video tells us the reason why we can't get the exact result. When we input 60, that's not the exact 60 to system. It's 60.00000XXXX to system, maybe. [bandicam 2022-01-24 16-07-38-316.mp4](https://archive.blender.org/developer/F12820683/bandicam_2022-01-24_16-07-38-316.mp4) [bandicam 2022-01-24 16-15-09-012.mp4](https://archive.blender.org/developer/F12820667/bandicam_2022-01-24_16-15-09-012.mp4)

Vladimir commented

2022-01-24 13:34:40 +01:00

Thank you @MarcoHoo-3! It interesting calculation with drivers!

Also additional information:

2022-01-24_15-13-55.mov

Thank you @MarcoHoo-3! It interesting calculation with drivers! Also additional information: [2022-01-24_15-13-55.mov](https://archive.blender.org/developer/F12821035/2022-01-24_15-13-55.mov)

Vladimir commented

2022-01-26 00:56:59 +01:00

Please to up priority because the problem affect doesn't only with EEVEE but even has in Cycles.

2022-01-26_02-40-52.mov

math.blend

Please to up priority because the problem affect doesn't only with EEVEE but even has in Cycles. [2022-01-26_02-40-52.mov](https://archive.blender.org/developer/F12824179/2022-01-26_02-40-52.mov) [math.blend](https://archive.blender.org/developer/F12824191/math.blend)

Vladimir changed title from ~~Node Math.Divide output incorrect result. Unstable result~~ to Math nodes output incorrect results. Unstable calculation

2022-01-26 01:11:08 +01:00

Jesse Yurkovich commented

2022-01-26 01:47:01 +01:00

No, in general you cannot rely on exact math when using floating point numbers. Here is your example above in standard C code: https://godbolt.org/z/s9xf11Ybb

Notice that the result is 5.9999990463 unfortunately. Floating point math can also behave slightly different based on if it's executed on the GPU (like with OpenGL) or otherwise.

No more videos about this are necessary. The report has been triaged and awaiting developer input on if there's anything that could improve the situation in certain circumstances. Probably not though.

No, in general you cannot rely on exact math when using floating point numbers. Here is your example above in standard C code: https://godbolt.org/z/s9xf11Ybb Notice that the result is 5.9999990463 unfortunately. Floating point math can also behave slightly different based on if it's executed on the GPU (like with OpenGL) or otherwise. No more videos about this are necessary. The report has been triaged and awaiting developer input on if there's anything that could improve the situation in certain circumstances. Probably not though.

Vladimir commented

2022-01-26 11:57:05 +01:00

Ok. But why I get different result between EEVVEE and Cycles?

Vladimir commented

2022-01-26 12:29:46 +01:00

Additionally, for C++ or C enough a simple multiply 0.56 * 10.0 that not to get 5.6 but when you multiply 0.56 * 100.0 you will get 56.0 exactly! Lol
In Java, Python for example, you will get 5.6 for floating operation 0.56 * 10.0.

Additionally, for C++ or C enough a simple multiply `0.56 * 10.0` that not to get `5.6` but when you multiply `0.56 * 100.0` you will get `56.0` exactly! Lol In [Java](https://godbolt.org/z/sWMsrM4z3), Python for example, you will get `5.6` for floating operation `0.56 * 10.0`.

Charlie Jolly commented

2022-01-26 12:35:54 +01:00

Floating point precision changes on the size of the numbers involved. What is displayed is not always the same as the underlying number. So in Python and Java you are seeing a rounded number for display.

I can see from a user perspective it is totally illogical!

Floating point precision changes on the size of the numbers involved. What is displayed is not always the same as the underlying number. So in Python and Java you are seeing a rounded number for display. I can see from a user perspective it is totally illogical!

Vladimir commented

2022-01-26 16:32:05 +01:00

In #95164#1295230, @Wovchick wrote:
In Java, Python for example, you will get 5.6 for floating operation 0.56 * 10.0.

Actually I was wrong. Sorry. You will get 5.6000000000000005 in Python and 5.59999990463256800000 в Java.

C++:
https://www.exploringbinary.com/the-answer-is-one-unless-you-use-floating-point/

IEEE 754

> In #95164#1295230, @Wovchick wrote: > In [Java](https://godbolt.org/z/sWMsrM4z3), Python for example, you will get `5.6` for floating operation `0.56 * 10.0`. Actually I was wrong. Sorry. You will get `5.6000000000000005` in Python and `5.59999990463256800000` в Java. C++: https://www.exploringbinary.com/the-answer-is-one-unless-you-use-floating-point/ [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)

Vladimir commented

2022-01-26 17:35:27 +01:00

For example:

>>> a = 0.56
>>> print("{:.{}f}".format(a, 16))

0.5600000000000001

>>> a == 0.56

True

When you input a constant from keyboard, Python remember it as 0.5600000000000001, so the comparison works. So what actually happens is this:

a == 0.5600000000000001

And so here is True, and here is False:

>>> a * 10

5.6000000000000005

>>> b = 5.6
>>> print("{:.{}f}".format(b, 16))

5.5999999999999996

>>> a * 10

5.6000000000000005

>>> a * 10 == b

False

The constant is less than multiply. In C++ something similar happens.

For example: ``` >>> a = 0.56 >>> print("{:.{}f}".format(a, 16)) 0.5600000000000001 >>> a == 0.56 True ``` When you input a constant from keyboard, Python remember it as `0.5600000000000001`, so the comparison works. So what actually happens is this: ``` a == 0.5600000000000001 ``` And so here is True, and here is False: ``` >>> a * 10 5.6000000000000005 >>> b = 5.6 >>> print("{:.{}f}".format(b, 16)) 5.5999999999999996 >>> a * 10 5.6000000000000005 >>> a * 10 == b False ``` The constant is less than multiply. In C++ something similar happens.

Jeroen Bakker commented

2022-01-26 17:55:06 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2022-01-26 17:55:06 +01:00

Changed status from 'Confirmed' to: 'Archived'

Jeroen Bakker closed this issue

2022-01-26 17:55:06 +01:00

Jeroen Bakker commented

2022-01-26 17:55:06 +01:00

Although interesting; floating point precision issues are not considered a bug.
Note that python doesn't use floats, but doubles and therefore has a higher precision.

The comparison is done on your GPU and with the way how the AMD/Intel driver optimizes the code. On older GPU more precision can be lost for performance reasons (fastmath operations or to reduce the physical space of sillicon).
Adding more precision in software (if possible) could lead to less performant shaders. I prefer to trade off performance vs precision towards performance especially in a rasterizer like Eevee.

The work around is to use a falloff in stead of a less than. I would prefer if this research would continue on devtalk or user forum.

Thanks you all for the detailed research and effort!

Although interesting; floating point precision issues are not considered a bug. Note that python doesn't use floats, but doubles and therefore has a higher precision. The comparison is done on your GPU and with the way how the AMD/Intel driver optimizes the code. On older GPU more precision can be lost for performance reasons (fastmath operations or to reduce the physical space of sillicon). Adding more precision in software (if possible) could lead to less performant shaders. I prefer to trade off performance vs precision towards performance especially in a rasterizer like Eevee. The work around is to use a falloff in stead of a less than. I would prefer if this research would continue on devtalk or user forum. Thanks you all for the detailed research and effort!

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

Math nodes output incorrect results. Unstable calculation #95164