System.Half ToString() bug

[c-ohle]

Description

System.Half ToString() produces incorrect numbers.

Example: Half.MaxValue shows 65500, Half.MinValue -65500
but should be 65504 and -65504.
Binary, the values are correct as I have checked:

Reproduction Steps

      var s1 = Half.MaxValue.ToString(); // 65500
      var s2 = ((double)Half.MaxValue).ToString(); // 65504

Expected behavior

      var s1 = Half.MaxValue.ToString(); // 65504

Actual behavior

      var s1 = Half.MaxValue.ToString(); // 65500

Regression?

No response

Known Workarounds

No response

Configuration

7.0.0-rc.1.22422.12

Other information

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[deeprobin]

Can reproduce.

@teo-tsirpanis Can you assign the right labels (bug and area-System.Numerics, I think)?

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

System.Half ToString() produces incorrect numbers.

Example: Half.MaxValue shows 65500, Half.MinValue -65500
but should be 65504 and -65504.
Binary, the values are correct as I have checked:

Reproduction Steps

      var s1 = Half.MaxValue.ToString(); // 65500
      var s2 = ((double)Half.MaxValue).ToString(); // 65504

Expected behavior

      var s1 = Half.MaxValue.ToString(); // 65504

Actual behavior

      var s1 = Half.MaxValue.ToString(); // 65500

Regression?

No response

Known Workarounds

No response

Configuration

7.0.0-rc.1.22422.12

Other information

No response

Author:	c-ohle
Assignees:	-
Labels:	bug, area-System.Runtime, untriaged
Milestone:	-

[tannergooding]

This isn't a bug, we return the "shortest roundtrippable string". Due to the underlying algorithm, it preferences 65500 over 65504, as both round to 65504.

You'd need to explicitly ask for G5 to see the longer version (the string that guarantees roundtripping without being the shortest possible) and G19 to see the most precise string.

[tannergooding]

Just to clarify, it's preferenced because 6.55e4 is shorter than 6.5504e4 (because 6.55 is 3 digits, where-as 6.5504 is 5 digits).

The algorithm doesn't take into account things like the length of e## or that we only use the e format for more than 6 or so digits. We just determine that 6.55 is the shortest sequence of significant digits (plus trailing zeros) that rounds to the infinitely precise value represented.

[c-ohle]

@tannergooding hi, there is a better and more simple algorithm that produces precise rounded string results. Not only for Half, not only for border cases. Check it out, you know where you can find it.

[tannergooding]

This is not a question about precision.

The current behavior is to return the shortest roundtrippable string and that is exactly what the algorithm is doing. This is the same behavior done by many different programming languages/runtimes and is done using one of the faster algorithms available. Changing this is undesirable and is not something we're interested in doing.

We have a different algorithm that will correctly and quickly compute a specific number of digits, which you can achieve using G5 for Half, as indicated above. G9 works for Single and G17 for double.

[c-ohle]

@tannergooding I know these things and I understand the situation. Cannot simply changed as users expect same results as previous versions. Are you aware that midpoint rounding is also wrong? for float and double too.
I followed many discussions over the years about this. What I do is to implement both, that the user can switch. Not ready yet since I completely rework the templates approach. All more compact and efficient now. It works great together with your INumber system.

[tannergooding]

Are you aware that midpoint rounding is also wrong? for float and double too.

Can you share an example? If this is Math.Round() I've already stated on the other issues that there is a longstanding known issue that's been around since .NET Framework.