(co-authored by Claude)
(%i1) e0 : 1-(log(2*%pi)-log(%pi))/log(2)$
(%i2) sign(e0);
(%o2) pos
(%i3) is(equal(e0, 0));
(%o3) true
(%i4) sign(radcan(e0));
(%o4) zero
(%i5) float(e0);
(%o5) 2.220446049250313e-16
The constant e0 is exactly zero, since log(2*%pi)-log(%pi) = log(2). sign() judges it by floating-point evaluation, and one bit of rounding turns the zero into pos — while is(equal(e0,0)) correctly says true. So sign and equal contradict each other on the same constant.
This is not just cosmetic: code that branches on the sign of a constant (the Gruntz limit code does, via mrv-sign) silently takes the wrong branch. A nonzero float verdict for a constant expression should be confirmed — for example at higher bfloat precision, or after a normalization — before it is reported; when in doubt, pnz would be honest.
I have a patch that, instead of a one-time numerical evaluation, evaluates constant expressions with increasing
bigfloatprecision and checks whether the result converges to zero.