Eq(RootOf(), y) evaluates as False

[oscarbenjamin]

Creating an Eq with a RootOf evaluates as False.

In [20]: x = Symbol('x')                                                                                                          

In [21]: y = Symbol('y')                                                                                                          

In [22]: r = RootOf(x**5 - x + 1, 0)                                                                                              

In [23]: Eq(r, y)                                                                                                                 
Out[23]: False

Since y is Symbol there is no way to know that it isn't equal to r so this should do the same as

In [24]: Eq(1, y)                                                                                                                 
Out[24]: 1 = y

[oscargus]

This is where it becomes false:

sympy/sympy/polys/rootoftools.py

Lines 964 to 965 in 27f2f10

	if not (other.is_number and not other.has(AppliedUndef)):
	return S.false

In [10]: y.has(AppliedUndef)
Out[10]: False

In [11]: y.is_number
Out[11]: False

As I teach digital design at the moment, I cannot help thinking that the if-clause is equivalent to:
not other.is_number or other.has(AppliedUndef), so clearly it is the other.is_number property that makes it fail.

[RituRajSingh878]

@oscarbenjamin instead of False. What should be the output?
I think we can raise ValueError.

[oscarbenjamin]

The result should be Eq(RootOf(x**5 - x + 1, 0), y).

[oscargus]

Not sure if I understand the questions, but if I do: most solutions are merged. Sometimes the solutions are too focused (like making sure that only this particular polynomial works correctly), but general solutions not breaking anything else are more or less guaranteed to be merged.

For this particular problem there is an ongoing PR which seems to progress so there may be better ones to spend effort.

[oscargus]

Without knowing the details in your case, it is quite common that issues are fixed in a very specific way and therefore not merged. Where that line is drawn is hard to in general. On one hand one can think that it is better to have a very specific fix than none and that someone else will fix it later. However, that rarely happens.

It takes a few attempts to get to know the code base and provide a good fix, so keep going! Personally, I have spent quite some time to improve the code quality without really adding any new functionality. In that way one gets to see lots of code and know Sympy a little bit better. There are still many things to clean up and improve from a coding perspective.

[oscarbenjamin]

@XtremeGood This issue is not the right place to discuss this (although I don't know what is the right place) but I will say this here: I think that your work in #15694 will get merged. Currently the code you wrote is in the first commit of #15992 as you can see here: https://github.com/sympy/sympy/pull/15992/commits
I can't say exactly when that will be merged because there are other problems to solve before that PR is ready.

[oscarbenjamin]

Actually it looks to me like #15923 has stalled. The proper fix is probably as described in this comment although it would need more tests to see that it does the right thing in different cases.