search

rtoy / maxima

A Clone of Maxima's repo
Other
0 stars 0 forks source link

Inconsistent handling of symbolic/float equality test #2849

Open rtoy opened 3 months ago

rtoy commented 3 months ago

Imported from SourceForge on 2024-07-06 23:15:32 Created by macrakis on 2015-05-03 08:59:27 Original: https://sourceforge.net/p/maxima/bugs/2952

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.

rtoy commented 3 months ago

Imported from SourceForge on 2024-07-06 23:15:33 Created by robert_dodier on 2015-05-06 21:02:13 Original: https://sourceforge.net/p/maxima/bugs/2952/#5319

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.