Apparent loss of percision when converting Rational -> double

[MReed2]

((double)Rational.Pow((Rational)0.95, 734)) != Math.Pow(0.95, 734)

Specifically, ((double)Rational.Pow((Rational)0.95, 734) == 4.4578585297200003E-17, while Math.Pow(0.95, 734) ==4.4578585297232747E-17. Wolfram Alpha agrees with Math.Pow, so I'm assuming that it is correct.

I suspect that the (double) conversion logic is converting to a decimal, then converting that to a double, because if you cast both to the decimal (instead of double) they do produce the same result.

Upon further examination, yeah, it looks like it is converting to decimal, then to double -- if you try to convert a small value into a double (which can handle smaller numbers than a decimal can), the underflow exception complain that "Value was either too large or too small for a Decimal." rather than the expected double.

Very odd problem -- I'd have assumed that decimal always has more significant digits than double, but apparently not (!?)

[tompazourek]

Thanks for writing up this issue!

Very odd problem -- I'd have assumed that decimal always has more significant digits than double, but apparently not (!?)

Me too, I guess the double (and possibly other floating-point) conversions will need to be revisited:

https://github.com/tompazourek/Rationals/blob/master/src/Rationals/ExplicitFloatingPointConversions.cs

I'm not yet sure what's the right solution to achieve the maximum possible precision here. But it's an interesting problem.