Setting rotation to PI is not equal to PI

[Logharn]

Tested versions

Reproducible in: 4.4.1.stable

System information

Windows 11 - Godot Engine v4.4.1.stable.official.49a5bc7b6 - https://godotengine.org Vulkan 1.4.303 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 4060 Ti

Issue description

Setting the rotation of a node to PI, is then approximated to a bit more than PI.

Steps to reproduce

Create a new project.
Create a Sprite2D node.
Add "icon.svg" as texture of Sprite2D.
Add a Timer as child of Sprite2D.
Attach a new script to Sprite2D.
Fill it with this code:

extends Sprite2D

# Called when the node enters the scene tree for the first time.
func _ready() -> void:
	$Timer.timeout.connect(on_timer_timeout)
	self.rotation = 0

func on_timer_timeout() -> void:
	print(self.rotation)
	self.rotation += PI

	if self.rotation >= TAU:
		print(PI)
		rotation = 0

The console Output will be:

0.0
3.14159274101257
3.14159265358979
0.0
3.14159274101257
3.14159265358979
...

In the inspector the rotation is reported correctly as 180.0° because it is rounded but in code is 180.000005008956

Minimal reproduction project (MRP)

Ready made project

rotation_test.zip

[Chaosus]

This is the expected disparity for floating-point numbers. Read: https://www.quora.com/Why-is-floating-point-arithmetic-not-exact

[Logharn]

Ok, but if I output simple maths, values are as expected.
What happens inside the rotation property that makes PI not PI?
Moreover how can I evaluate if a node is rotated by PI?
Because if in the _ready() I put:

self.rotation = PI
print(self.rotation == PI)

returns false

I've to transform radians in degrees and then round it to the nearest integer?

[akien-mga]

You can use is_equal_approx(self.rotation, PI), see the notes in the float documentation:
https://docs.godotengine.org/en/latest/classes/class_float.html#description

[timothyqiu]

I think it's fair to expect that 0 + x == x even if x is a floating-point number.

The actual problem here is that rotation being 32-bit, while PI (a regular float) being 64-bit.

We could improve the documentation for special properties / parameters / return values like this. Otherwise, the only way to find out the reason is to check to source code for the use of real_t.