Always add decimal when converting float to string

[KoBeWi]

So that

var a: float = 1
print(a)

prints

1.0

Makes working with numbers less confusing. I remember someone mentioned it around godotengine/godot-proposals#1866

Closes godotengine/godot-proposals#7894

[Calinou]

Does this change apply automatically to floats within Vectors/Colors/Transforms/Matrices as well?

[KoBeWi]

Hmm, it doesn't. Changing it might be not as easy :I

[KoBeWi]

Ok, so I extended this to these types (in addition to floats): Vector2, Rect2, Vector3.
The original aim was to differentiate integer types from floats. As we don't have AABBi or Basisi I left these types untouched.

[dalexeev]

Also need to solve this problem:

print(5.0)                    # 5
print(5.0000001234)           # 5 <--
print("%.16f" % 5.0)          # 5.0000000000000000
print("%.16f" % 5.0000001234) # 5.0000001234000004

$ python3 -q
>>> print(5.0000001234)
5.0000001234

[KoBeWi]

The precision problem doesn't look related.

[dalexeev]

The precision problem doesn't look related.

The problem is not with the precision of the numbers themselves, but that print doesn't display the number as precisely as it could. This can be seen by the fact that everything works with the formatting operator.

[KoBeWi]

Ah, right. I don't know how to fix this tbh. I can't use is_equal_approx() in FLOAT_STRING, because it produces stuff like 1.00001.0.

Well maybe I could search for . inside the resulting String 🤔

[KoBeWi]

Ok changed it. Here's the FLOAT_STRING as it was originally:

#define FLOAT_STRING(f) (rtos(f) + (Math::floor(f) == f ? ".0" : ""))

The new one is slightly less efficient, but maybe it doesn't matter that much.

[akien-mga]

We approved the change in a PR review meeting today, though we were concerned about the performance cost of the FLOAT_STRING define (doing a costly calculation twice + a find()).

A better option might be to use String::num_real() instead of String::num(), which already takes care of adding a .0 where relevant. I'm not sure how num() and num_real() differ aside from that and whether there would be some stuff handled by the one and not the other.

[KoBeWi]

Rebased and reworked. I removed the macro and just changed usages of String::num_real() to use true as second argument (which makes the .0 always appear). I did it in the operators instead of stringify() method to avoid duplicating formats. As a result, some more classes are affected, e.g. Basis, which uses vectors.

print(1.0)
print(Vector2.ONE)
print(Rect2(Vector2.DOWN, Vector2.ONE))
print(Basis())

->

1.0
(1.0, 1.0)
[P: (0.0, 1.0), S: (1.0, 1.0)]
[X: (1.0, 0.0, 0.0), Y: (0.0, 1.0, 0.0), Z: (0.0, 0.0, 1.0)]

[KoBeWi]

So I just noticed that changing Variant::stringify() will affect generated docs (as seen in failed CI, PI and TAU lose their precision). Not sure if that's ok 🤔

[akien-mga]

This seems to break the generated Mono glue:

/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/VisualScript.cs(125,84): error CS1503: Argument 1: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/VisualScript.cs(125,89): error CS1503: Argument 2: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/TextParagraph.cs(351,110): error CS1503: Argument 1: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/TextParagraph.cs(351,115): error CS1503: Argument 2: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]

CC @godotengine/mono

[raulsntos]

@akien-mga It's likely because the bindings generator now generates code using literal 0.0 (which is a double in C#) instead of 0 (which is an int). An int can be implicitly converted to a float but a double cannot be implicitly converted to a float because of precision-loss so in methods that take a float it fails.

The generator uses operator String() to generate the constructor for the default value of variants:

godot/modules/mono/editor/bindings_generator.cpp

Lines 3188 to 3207 in 44516d1

	case Variant::PLANE: {
	Plane plane = p_val.operator Plane();
	r_iarg.default_argument = "new Plane(new Vector3" + plane.normal.operator String() + ", " + rtos(plane.d) + ")";
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::AABB: {
	AABB aabb = p_val.operator ::AABB();
	r_iarg.default_argument = "new AABB(new Vector3" + aabb.position.operator String() + ", new Vector3" + aabb.size.operator String() + ")";
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::RECT2: {
	Rect2 rect = p_val.operator Rect2();
	r_iarg.default_argument = "new Rect2(new Vector2" + rect.position.operator String() + ", new Vector2" + rect.size.operator String() + ")";
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::RECT2I: {
	Rect2i rect = p_val.operator Rect2i();
	r_iarg.default_argument = "new Rect2i(new Vector2i" + rect.position.operator String() + ", new Vector2i" + rect.size.operator String() + ")";
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;

godot/modules/mono/editor/bindings_generator.cpp

Lines 3251 to 3287 in 44516d1

	case Variant::TRANSFORM2D: {
	Transform2D transform = p_val.operator Transform2D();
	if (transform == Transform2D()) {
	r_iarg.default_argument = "Transform2D.Identity";
	} else {
	r_iarg.default_argument = "new Transform2D(new Vector2" + transform.columns[0].operator String() + ", new Vector2" + transform.columns[1].operator String() + ", new Vector2" + transform.columns[2].operator String() + ")";
	}
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::TRANSFORM3D: {
	Transform3D transform = p_val.operator Transform3D();
	if (transform == Transform3D()) {
	r_iarg.default_argument = "Transform3D.Identity";
	} else {
	Basis basis = transform.basis;
	r_iarg.default_argument = "new Transform3D(new Vector3" + basis.get_column(0).operator String() + ", new Vector3" + basis.get_column(1).operator String() + ", new Vector3" + basis.get_column(2).operator String() + ", new Vector3" + transform.origin.operator String() + ")";
	}
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::BASIS: {
	Basis basis = p_val.operator Basis();
	if (basis == Basis()) {
	r_iarg.default_argument = "Basis.Identity";
	} else {
	r_iarg.default_argument = "new Basis(new Vector3" + basis.get_column(0).operator String() + ", new Vector3" + basis.get_column(1).operator String() + ", new Vector3" + basis.get_column(2).operator String() + ")";
	}
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;
	case Variant::QUATERNION: {
	Quaternion quaternion = p_val.operator Quaternion();
	if (quaternion == Quaternion()) {
	r_iarg.default_argument = "Quaternion.Identity";
	} else {
	r_iarg.default_argument = "new Quaternion" + quaternion.operator String();
	}
	r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
	} break;

For example, we use it to generate new Vector2(0, 0) but now, because of this PR, it generates new Vector2(0.0, 0.0) which won't work because the Vector2 constructor takes floats not doubles.

[aaronfranke]

For the Mono bindings generator, we'll probably need to manually generate each piece of the constructor.

[Mickeon]

Tangentially related, the more time passes the more appropriate it looks to me to trim the trailing zero out of SpinBoxes. Whether that should be a setting or just done intrinsically is up to debate.

We can add a utility method that converts float to String and trims zero when necessary.

Could this be a placeholder modifier for format Strings? Is there also a programming language that faces a similar issue? If yes, what's their solution?

It's looking like this PR is only objectively favoured when printing floats, but actually having that work would be vastly inconsistent with the str() method which print itself uses, so that's not an option.

[aaronfranke]

Regardless, we should provide methods for each style of behavior. Users shouldn't need to write str(float_value).trim_zero().

Would anyone like to propose APIs for these cases?

• If this PR is kept, what should the non-.0 function be called?
• If this PR is reverted, what should the .0 function be called?

[PraxisMapper]

I think this change causes my project that runs fine in 4.3 to throw errors in 4.4 dev4.

I have several data files generated by a separate C# app, where keys in a dictionary are ints that can be referenced by other data files. The trick is that C# exports JSON dictionaries with int keys as strings instead, and I have not found a way to disable/change that behavior, so when I go to do that lookup I end up with something like
DataDict[str(RefKey)]
which works fine in 4.3. In 4.4 dev4, these need to be changed to
DataDict[str(int(RefKey))]
because RefKey is now being interpreted as a float when it's read from JSON, even though there's no decimal on it anywhere.

This isn't a difficult change for me to make, but it's a surprise than this applies to all numeric values loaded from JSON.

[aaronfranke]

The trick is that C# exports JSON dictionaries with int keys as strings instead, and I have not found a way to disable/change that behavior

You can't change this behavior, because the JSON format only supports strings as keys. Trying to use an int as a key would make it no longer a valid JSON file.

I'm curious where you are getting RefKey from. Is it a read as a value from elsewhere in the file, as a number value? If so, that makes sense, because JSON does not have integers, all numbers are just "number". If the data format you are using has values that refer to keys, then I would suggest making those values strings, because that is type-correct with JSON. So the value would be "5" instead of 5 for example. This also gives you freedom to move to other conventions in the future, such as if you wanted to point to a key of "apple" or a UUID instead of a number.

[TheYellowArchitect]

var current_level: int = 12
print(current_level)

would print 12 before this PR, but now prints 12.0
My code for what broke in my project:

var current_level: int = 12
	while current_level > target_level:
		level_holder.get_node("Level" + String.num(current_level)).hide()

the fix after this PR

var current_level: int = 12
	while current_level > target_level:
		level_holder.get_node("Level" + String.num(current_level).replace(".0","").hide()

Edit: This PR has broken all my serialization, its not just the above. All my integers which are converted to string suffixes to search files, don't work

[KoBeWi]

would print 12 before this PR, but now prints 12.0

It doesn't

the number is int.

String.num() works with floats. Just use str().

[TheYellowArchitect]

Thank you for the swift response - was already changing my conversions so I am glad you replied before I continued.
You are right that just using str() instead of String.num() doesn't print integers as floats 👍

[jerryjrowe]

I'm pretty sure this is the right thread---
Integers are getting the extra ".0" on them all over the place, in internal functions, even.

With sign(), specifically, it used to return 1, 0, -1.
Now it returns 1.0, 0, -1.0

And since 1 as an integer isn't the same thing as 1.0, anything that tries to, say, match a value with sign() will not work as intended.

Also, a related weird thing that is definitely happening on Linux...

If you have a variable like @export var neato_dictionary : Dictionary[String,Variant] { "thing_one" : 1, "thing_two" : 1.0, }

..if you iterate over the values in the dictionary, it'll recognize the former as an int, and the latter as a float.

But when you use str(neato_dictionary.values()[0] (or anything similar to get to that specific value), it'll print "1.0" not "1"

[Mickeon]

Neither of the above seem to happen in v4.4.dev.custom_build [06bb994]:

	print(type_string(typeof(sign(2))))   # Prints int
	print(type_string(typeof(sign(2.5)))) # Prints float
	
	var dict: Dictionary[String, Variant] = { "thing_one" : 1, "thing_two" : 1.0, }
	print(dict.values()[0]) # Prints 1

And they would not be caused by this PR, either way.

[KoBeWi]

Note that sign() takes and returns Variant, so if you got float, it means your argument is float. Make sure the argument is int or use signi() instead.

[akien-mga]

To be clear, the only thing changed by this PR is that floating-point numbers with a whole value (which is not the same thing as integers, 3 != 3.0) will now be printed with a trailing .0 to make it clear that they are indeed floating point numbers and not integers.

So if you thought you were dealing with integers and this PR has changed those numbers to have a .0 suffix, you were actually dealing with floats and the purpose of this PR is precisely to help prevent this confusion.

[iegehang]

Hello, I needed a feature included only in 4.4 version. So I switched my project. But I'm currently having a problem with this pull feature now. All integer values are returning wrong in WebApi responses. For example; item_id stored as 1 is now 1.0. When I set this responses in a "json" object, all i see is values like 1.0, 2.0 etc. Now I have to convert whole project responses prior to that which is 19k lines of codes. Isn't there an option to change this in a projectwide?

Edit: I suspected something during serialization; while getting HTTP responses; I am using "JSON.parse_string(body.get_string_from_utf8()" as suggested in official documents. If ".0" appears at the end of integer values just because we are using "get_string_from_utf8" function, this needs to be fixed.

[Calinou]

Edit: I suspected something during serialization; while getting HTTP responses; I am using "JSON.parse_string(body.get_string_from_utf8()" as suggested in official documents. If ".0" appears at the end of integer values just because we are using "get_string_from_utf8" function, this needs to be fixed.

JSON doesn't have an integer type. Instead, it only has a number type which is parsed as a float in most implementations. Some implementations have a way to force integers to be used when parsing JSON; see godotengine/godot-proposals#8830.

[iegehang]

Edit: I suspected something during serialization; while getting HTTP responses; I am using "JSON.parse_string(body.get_string_from_utf8()" as suggested in official documents. If ".0" appears at the end of integer values just because we are using "get_string_from_utf8" function, this needs to be fixed.

JSON doesn't have an integer type. Instead, it only has a number type which is parsed as a float in most implementations. Some implementations have a way to force integers to be used when parsing JSON; see godotengine/godot-proposals#8830.

Problem here is you can't deny lots of people using serialization and api results are always the same just because of a .0 extension to an integer value as i never saw before in any other languages. Now all data we have been using requires a deep refactoring. PR should have been confirmed after a little thinking about consequences.

[Zireael07]

JSON is a standard. It does not have "integers". You seem to have been misusing the standard. This PR's main goal was to make floats vs integers explicit and it surfaced that a lot of folks have been using one when they meant the other.

[iegehang]

Oh sir, please read what i am telling up there and try to understand my point. JSON has integers or not, that's no matter. One way or another serialization is part of lots of projects. IF a PR effecting a common usage, you have to "think" about the consequences before applying it. This PR is affecting usage of serialization clearly because it seems like anything inside the "get_string_from_utf8" forced out to print ".0". In a very basic response of mine; sql stores the value as 1, WebAPI stores the value as 1. But Godot converts it to 1.0 during serialization. Just why? What would happen if you apply this PR to a language like Javascript. Can you imagine the chaos? Well I took a look at whole issues and repository logs here and I don't understand why Godot developers became so arrogant. Everyone has a meaningless fanaticism over things. Anyway I'm simply saying again; this PR made a method meaningless that has been used frequently.

[dalexeev]

As said above, the JSON specification does not distinguish between int and float, there is only Number. Regardless of the presence or absence of trailing .0 in a JSON string obtained using JSON.stringify(), after deserializing the string using JSON.parse_string() you always get a float. This has not changed, in 4.3 the same behavior, you can check this with typeof() or var_to_str().

@tool
extends EditorScript

func test(value):
    var decoded = JSON.parse_string(JSON.stringify(value))
    prints(value, type_string(typeof(value)),
            "->", decoded, type_string(typeof(decoded)))

func _run():
    test(1)
    test(1.0)

4.3:

1 int -> 1 float
1 float -> 1 float

master:

1 int -> 1.0 float
1.0 float -> 1.0 float

Although 1 == 1.0 evaluates to true, these are values ​​of different types and in many cases they are considered unequal (dictionary keys, match patterns, etc.). This change is that other string conversions (str(), print(), and some others) now make this more obvious. The previous behavior was confusing and misleading (for instance, print({ 1: "a", 1.0: "b"}) prints { 1: "a", 1: "b" } in 4.3).

I'm sorry to hear that this seems to have been a significant nuisance for you. However, you probably already had hidden bugs due to Godot's non-obvious behavior. It's possible that the bugs didn't show up because of implicit type conversions, but it's too risky and fragile to rely on that. This change just exposed the real problem, the mismatch between your expectations and how it actually works.

Regarding conversions between native and JSON types, we recently added a new API that is intended to be as preserving and unambiguous a conversion as possible. Unfortunately the current implementation has several flaws, so I've opened PR #99765 to fix them.

[iegehang]

Thank you for your reply sir. Honestly I had upgraded from 4.2 to 4.4. I literally had no idea, 4.3 also had this conversion. Thanks for the #99765