Displaying of integers is sometimes really surprising (from gforge #20353)
Imported issue: Initially reported by @chevilla in https://gforge.inria.fr/tracker/?group_id=1015&aid=20353
The following session is quite surprising, although it seems that it perfectly corresponds to the documented behavior of Sollya:
> p = 206987/2048;
> q = 119504/2048;
> r = p^3 * (p^16 + 6561 * q^16 - 17496*p^2*q^14 + 20412*p^4*q^12-13608*p^6*q^10+5670*p^8*q^8-1512*p^10*q^6+252*p^12*q^4-24*p^14*q^2) - q;
> rationalmode = on;
> r;
-4.8008881010281593472091659470784166427440804076920736140878158093e64 / 8.227522786606030210774845912786752524913679328168e62
> prec = 12;
The precision has been set to 12 bits.
> r;
-4.8008881010281593472091659470784166427440804076920736140878158093e64 / 8.228e62
> -4.8008881010281593472091659470784166427440804076920736140878158093e64;
-4.8008881010281593472091659470784166427440804076920736140878158093e64 / 1
> 8.228e62;
Warning: rounding has happened. The value displayed is a faithful rounding to 12 bits of the true result.
8.228e62
What is surprising is that r is an exact rational (which Sollya recognizes) but when displaying it, this does not appear clearly. Indeed, at default precision, the displayed fraction gives the true numerator and true denominator, although it is not obvious that they are integers.
At precision 12, it is surprising that the numerator is still a very long decimal expression (which turns out to be exact) but the denominator is a very small decimal expression (which is not exact, but is rounded to the exact value, when read at precision 12).
In fact the denominator is exactly 2^(209) which is exactly representable on 12 bits. So, Sollya chooses a representation as a short decimal value that rounds to 2^(209) when read at precision 12.
However, it is weird that we simultaneously have
-
the numerator given as a long decimal number which is interpreted as an exact integer, although it is not representable on 12 bits
-
and the denominator given as a short decimal constant (which could also be interpreted as an exact integer), but that is interpreted as a constant that should be rounded to 12 bits in order to recover its value...
It is confused. In which case does Sollya interpret a decimal constant as an exact floating-point integer and in which case does it round it at current precision to retrieve the corresponding value?
And finally, we now get funny behaviors like:
> denominator(simplify(r));
8.228e62
> denominator(simplify(r)) == 2^(209);
true
> 8.228e62 == 2^(209);
false
> 822800000000000000000000000000000000000000000000000000000000000;
Warning: rounding has happened. The value displayed is a faithful rounding to 12 bits of the true result.
8.228e62
> 822800000000000000000000000000000000000000000000000000000000000 == 8.228e62;
true
.... because Sollya now does exact (infinitely accurate) comparisons when given constant expressions.
I think we should re-think once and for all how we display decimal constants in Sollya.