`long.ToMetric` interprets `decimals` as a required number of fixed decimals instead of desired precision

[logiclrd]

Recently, long.ToMetric support was merged. This method parallels int.ToMetric in its specification. However, as was pointed out by @petervanleeuwen, its interpretation of the decimals parameter is incorrect.

   ((int)1).ToMetric(decimals: 5) => "1"
   ((long)1).ToMetric(decimals: 5) => "1.00000" // should be "1" as with int

I will create a PR that corrects this shortly.

[wyf027]

Addressed in #1795 (CI green, approved).

[wyf027]

PR #1795 aligns long.ToMetric decimal handling with int (fixes the 1.00000 vs 1 mismatch). Azure CI green, CodeRabbit approved.

[logiclrd]

@leno23 Why would you create a new PR when there is already a comprehensive PR for this issue?

[logiclrd]

Original PR #1700 has been rebased and updated to resolve issues identified by CodeRabbit, now approved.

[logiclrd]

I just transplanted the extended tests from #1700 into #1795 and it reveals a number of cases that are not handled properly. For instance, 123456L.ToString(decimals: 20) should format as 123.456k, but #1795 still formats it as 123.45600000000000000000k.

At a glance, it looks like #1795 only addresses the path where no scaling is required (numbers in the range [-999, 999]).

[wyf027]

Thanks @logiclrd — agreed. #1795 was a partial fix and I'm closing it in favor of #1700, which already has the comprehensive test suite and full BuildRepresentation(long, …) rework. #1700 is CI green + approved on my last check.

Happy to help review or test #1700 if useful.