Include `math.sign`

[oscarbenjamin]

@tim.one

So I tried

e = log(sin(4)**2 + cos(4)**2)

It’s exactly 0, but sympy doesn’t simplify it by magic. WYSIWYG.

type(e) is log, and type(e)(0) is a “complex infinity”. Not even close to 0 to my eyes .

However, then things appear to get messy: e == 0 returns False (although the mathematically exact value is 0), but float(e) returns 0, as doese.evalf(). e < 0, e == 0, and e > 0 all return False. Although bool(e) returns True.

I sort of explained this in another thread:

Add operator support for mathematical equivalence

I think that there isn’t really a single notion of equality but there is only one == operator so people have used it for different things. Even without pathological examples == is a mix of structural equality and mathematical equivalence: In [1]: [1, 2] == (1, 2) Out[1]: False In [2]: [1.0, 2] == [1, 2] Out[2]: True A general mathematical equivalence operator is impossible to define or implement but structural equality is something that can be given a well defined meaning and has many uses. …

The issue is that == is what is used by dict and set so you have to choose between defining == in a way that makes the expressions efficiently hashable vs defining == as mathematical equality. SymPy chooses the hashable version but that means that == is not in the same semantic plane as < and > and the equality operator that corresponds to < is actually spelled as Eq(a, b) rather than a == b:

In [1]: e = log(sin(4)**2 + cos(4)**2)

In [2]: Eq(e, 0)
Out[2]: True

Note that if you want to use that reliably you have to spell it like

if Eq(e, 0) == True:

because bool(Eq(e, 0)) can blow up on you for some expressions.

The alternative choice that a == b be equivalent to Eq(a, b) would make == semiundecidable even for well-defined simple numeric expressions.