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

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:

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 15 (10 by maintainers)

Most upvoted comments

It exists as a concept in various higher level mathematics… The wikipedia article on Signed zero mostly talks about the computational usage around IEEE 754, but also briefly delves into some mathematical and scientific applications of it.

It is really not true that it exists as a concept in any pure mathematics. No mathematical usage is mentioned in the wikipedia article. There is only a negative temperature usage mentioned where it seems to be casual notation for either an informal negative infinitessmial or tending to zero from below. The linked reference is not publically accessible and a search does not bring up other usages on this topic.

It is, in my opinion, something that people should be aware of when dealing with float/double (in any language), same as they should be aware that 0.3 is not exactly representable

I agree that people should be aware that 0.3 is not exactly representable, i.e. of fundamental limitations of floating point representations. However negative zero is a quirk which, unless it’s deliberately exposed to you as it is here, is only of interest if you maintain numerical libraries. I happen to know that it exists because I maintain numerical libraries, and the quirks of -0 and atan2 affect correctness. But it’s really not of relevance to most programmers, who use floating point numbers but do not in a way that needs to distinguish between -0.0 and +0.0.

The change is documented alongside the other breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/compatibility/2.2-3.0#floating-point-formatting-and-parsing-behavior-changed.

This links to https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/ for more details, and the changes mentioned in these links - which seem perfectly good - don’t address -0 at all.

I don’t really know what form the warning should be given but any docs about formatting floats need to put -0 behavior and how to remove it up front because the default will be almost always incorrect in released code.

charlesroddie on Feb 19, 2020

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

OK 5.12.2 does contain conditions on preserving sign, which on a strict interpretation of the doc would include negative for zero.

including in higher mathematics where -0 is a concept

This is not correct. 0 is the additive identity in mathematics and “-0=0” follows from “-0=0±0=0”. Signed zero does not exist in mathematics and only in numerical computing (and even there mostly when discussing the IEEE 754 standard). Any article serach will confirm this.

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).

These look too hard and unfinished. If someone has to look up a thread to work out how to avoid “-0” then this has already failed. The API should bear in mind that 99.999% of devs would not want “-0” and if displayed to end users it would always be a bug. So getting “0” should be as easy as possible and getting “-0” should not be easier and should have some sort of warning/xml doc/other hurdle.

Adding a String.FormatIEEE754 method for the special purpose of displaying negative zero as “-0” would be one option.

The IEEE 754 5.12.2 generates prolems across many languages where people are always asking how to get rid of “-0”. Always add zero before converting to strings seems to be a popular recommendation! It’s important to minimize this problem.

charlesroddie on Feb 19, 2020

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

danmoseley on Feb 19, 2020

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.

charlesroddie on Feb 18, 2020