Godot: Dividing A Vector2/Vector3 by Zero Doesn't Cause an Error

[matthew1006]

Godot Version: 3.1
OS: Windows 7

Dividing any vector by zero does not result in a Division by Zero error but instead results in a vector with components with values 1.#INF i.e. Vector2(1.#INF, 1.#INF).
This is also true in 3.0 and 2.1 (in 2.1 you get Vector2(inf, inf)).
Is this intended behaviour because is probably shouldn’t be as anything divided by zero is undefined? It seems like this could cause a debugging nightmare with silent zero divisions going unnoticed and causing havoc.

Steps to Reproduce:
1) Divide a Vector2 or Vector3 by zero.
2) Notice that there is no error and the game doesn’t complain.

[Zylann]

Does dividing a float by zero cause an error? If not, then so does Vector2 and Vector3.
(Integers, on the other hand, do cause errors because the CPU actually considers it as one)

[matthew1006]

Dividing a float by zero does cause an error.

If dividing a float by zero didn't cause an error then that would be an even bigger problem as dividing by zero doesn't equal infinity, it's undefined.

In the limit x → 0:
    x/x → 0/0 → 1
    0/x → 0/0 → 0
    +1/x → 1/0 → infinity
    -1/x → -1/0 → -infinity.

So having anything divided by zero evaluate to +infinity is not only going to cause errors that are hard to catch but is mathematically incorrect.

[isaacremnant]

1/0, 1.0/0, 1.0/0.0 all produce the error, so maybe Vector2/0 should too for consistency, although I suspect it's better this way.

x/x → 0/0 → 1

This is not correct notation. x/x=1. lim_{x->0+} 1/x = infinity is an actual equality. But that's math, it has nothing to do with implementation. The notion that 1.0/0.0 = INF is just a tool to handle such cases gracefully. For instance, atan(INF) = PI/2 is useful and captures the limit of the function accurately even if it's not "mathematically correct".

[matthew1006]

In my own project I had a problem where I was getting nonsense values. After tracing these values back to their source I found a Vector2 being divided by delta in _process which was zero on some frames (#26887). If there was an error then I wouldn't have had to spend time looking for it. If the value hadn't been used for something visual then I may not have noticed it at all.

I disagree that it is better this way. If x/0 is going to evaluate to anything it should be NaN. It even says so in the docs:

The NaN values are used to identify undefined or non-representable values for floating-point elements, such as the square root of negative numbers or the result of 0/0."

https://docs.godotengine.org/en/latest/classes/[email protected]?highlight=NaN

[matthew1006]

After further reading and tests I’ve learned that Godot doesn’t throw an ‘Division by Zero’ error in release builds when dividing floats by zero and that the behaviour of returning +infinity for 1.0/0.0, -infinity for -1.0/0.0 and NaN for 0.0/0.0 is actually standard behaviour defined in IEEE 754.

I’ll leave this open as Godot does do zero division checks on floats when debugging is enabled and I think that the same checks should be extended to Vectors (and Colors as they don’t check either!).

I suppose there is a question of whether Godot should adhere to the IEEE 754 standard* or if it should strictly disallow all divisions by zero as Python does.

*[Really it’s C++ that seems to be following the standard with Godot just using its built-in arithmetic.]