#2952 Inconsistent handling of symbolic/float equality test

[Stavros Macrakis]

is(equal(float(%pi),%pi)) => true

This is problematic, but let's suppose it's intended behavior.

But now:

is(equal(float(%pi/2),%pi/2));
rat: replaced 1.570796326794897 by 37362253/23785549 = 1.570796326794895
false

Oops. Clearly the equality doesn't hold in either case, but in the first case, Maxima treats the approximation as exactly correct.

Both of these should be comparing against the exact value of %pi, so k*%pi should NEVER compare equal to any float (except of course with k=0).

Bizarrely, sign(%pi/2-float(%pi/2)) => zero.

[Robert Dodier]

Something that happens at program launch (not sure of the exact mechanism) is that something equivalent to assume(equal(foo, float(foo))) is executed for various constants foo, among them %pi. I agree that these assertions are suspicious, although I wonder what would break if they were omitted.

sign(%pi/2-float(%pi/2)) takes a different path than is(equal(%pi/2, float(%pi/2))), in particular, the latter calls DCOMPARE, DCOMP, and DINTERNP, and the former doesn't. It makes sense to me to unify sign and is(equal(...)), although again I wonder if anything would break.