Numeric comparison fails when it should succeed.

[manfred-brands]

@stevenaw This fails on 3.13-dev, but succeeds on 3.13.2, it was introduced with #3898

[Test]
public void Decimal()
{
    const double value = 1.0000000000000038d;

    Assert.Multiple(() =>
    {
        Assert.That(value > 1.0, Is.True, "> 1.0");
        Assert.That(value, Is.GreaterThan(1.0), "Is.GreaterThan(1.0)");
    });
}

This fails with:

Message: 
  Is.GreaterThan(1.0)
  Expected: greater than 1.0d
  But was:  1.0000000000000038d

The error is in the conversion to decimal. Despite the type claiming to have 28 digits of precision,
Convert.ToDecimal(value) results in 1 dropping all fractional digits.

Even though the comparison uses decimal the error message uses the original values.

[manfred-brands]

The rounding seems to be deliberate in System.Decimal's DecCalc

// Round the input to a 15-digit integer.  The R8 format has
// only 15 digits of precision, and we want to keep garbage digits
// out of the Decimal were making.

[rprouse]

That code could be left over from a very old version of NUnit from when the CLR only had 15 digits of precision? It predates me but it looks like a bug.

[manfred-brands]

That code reference is from the current roslyn repository. .NET 6.0 SDK

[manfred-brands]

What was the reason to convert always to decimal?
I agree that if one operand is decimal we should use decimal comparison.
I would even go that far that if both types are float we should not use double compare either.