System.Single.ToString() behavior changed from netcoreapp2.2 to netcoreapp3.0 (returns "-0")

[bencameron]

class Program
{
	static void Main(string[] args)
	{
		var foo = new Foo();
		var barString = foo.Bar.ToString();
		var negBarString = foo.NegativeBar.ToString();
		var ver = Assembly.GetEntryAssembly()?
			.GetCustomAttribute<TargetFrameworkAttribute>()?.FrameworkName;

		Console.WriteLine($"Target Framework: {ver}");
		Console.WriteLine($"Bar: {barString}");
		Console.WriteLine($"NegativeBar: {negBarString}");
	}

	private class Foo
	{
		public float Bar => 0f;
		public float NegativeBar => -Bar;
	}
}

Results:

[stephentoub]

cc: @tannergooding

[tannergooding]

This change is by design and was done for IEEE 754 compliance. This blog post goes into more detail about the range of changes that occurred: https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/

[charlesroddie]

This change is by design and was done for IEEE 754 compliance. This blog post goes into more detail

The blog does claim it is making parsers and formatters IEEE 754-2008 compliant. However I cannot find anything about strings (or parsing, or formatting) in the IEEE 754-2008 document.

Displaying "-0" makes .ToString() on floating point numbers suitable for low-level debugging only. I think it's a bad decision.

[tannergooding]

However I cannot find anything about strings (or parsing, or formatting) in the IEEE 754-2008 document.

It is covered in 5.12 Details of conversion between floating-point data and external character sequences:

5.12.1 External character sequences representing zeros, infinities, and NaNs
The conversions (described in 5.4.2) from supported formats to external character sequences and back that
recover the original floating-point representation, shall recover zeros, infinities, and quiet NaNs, as well as
non-zero finite numbers. In particular, signs of zeros and infinities are preserved.

Displaying "-0" makes .ToString() on floating point numbers suitable for low-level debugging only. I think it's a bad decision.

It was what the majority of languages/frameworks that are IEEE 754 compliant (which is most of them) do (including C/C++, Rust, Javascript, Python, etc).

[danmoseley]

What format specifier (or workaround) should @charlesroddie use if he wants "default but with no -0" ?

[tannergooding]

There isn't a way to not print -0 with standard format strings. For those, you need to explicitly convert -0 to +0 (x != 0 ? x : 0 should work).

For custom numeric format strings "0;-0" should currently work as zero hits the first path, not the second (we may have an issue on this, as custom numeric format strings were largely left untouched and we were to revisit them in the future).

[nikolayDemirev]

But what about -0.01 formatted with "0" it will return "-0" you can't work around it with the ternary operator? Do you think there might be some legacy mode or something for all software migrating from older version of the Framework to 3+?

[tannergooding]

But what about -0.01 formatted with "0" it will return "-0" you can't work around it with the ternary operator?

The three format section separator works: https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings#the--section-separator. That is Console.WriteLine($"{-0.01:0;-0;0}"); will print 0.

Do you think there might be some legacy mode or something for all software migrating from older version of the Framework to 3+?

There is not currently. There were also a lot more fixes that went in aside from the formatting fix for negative zero (including fixes around formatting/parsing correctness). Maintaining the incorrect legacy code has a non-trivial cost and I don't think it is worth the trade-off.

Having programs update use custom numeric format specifiers to control the printing behavior of 0 and -0 would be the most forward and backward compatible option.

[charlesroddie]

@tannergooding Thanks for the link to the relevant part of IEEE 754-2008. The wording provides a suitable way to limit this. conversions from supported formats to external character sequences and back that recover the original floating-point representation.

So for compliance there should exist a string serializer to a decimal string (which could be .ToString() which can be reversed to give a float with exactly the same bits as the original) and which needs to write "-0" in some form.

There is no need for this to apply to rounded or formatted strings which are not designed to represent the floating point number precisely at a low level. The purpose of formatting is not for low-level debugging but to present to users running released code.

[tannergooding]

There is no need for this to apply to rounded or formatted strings which are not designed to represent the floating point number precisely at a low level

Other parts of the spec detail rounding requirements around specialized format strings. For example 5.12.2 External decimal character sequences representing finite numbers:

Conversions to and from supported decimal formats shall be correctly rounded regardless of how many
digits are requested or given.

The purpose of formatting is not for low-level debugging but to present to users running released code.

That is one purpose of formatting. It is equally valid for it to be used for serialization or other purposes. We are now performing IEEE 754 compliant formatting by default and provide custom numeric format strings that allow you to otherwise specialize the behavior (including removing the sign from 0). This is no different than the formatting for any of the other integral types which are correctly rounded and displayed by default but can be customized using custom formatters when you have exact display requirements.

IEEE 754 binary floating-point values are usable in a range of scenarios, including in higher mathematics where -0 is a concept and can impact the computation of your overall algorithm (and which has to be taken into account when dealing with infinities, complex numbers, and other scenarios).