Comment #3 on issue 2343 by [email protected]: as_poly returns None
http://code.google.com/p/sympy/issues/detail?id=2343
To me this is yet another consequence of the current state of art in
assumptions:
In [1]: u0 = Symbol('u')
In [2]: u1 = Symbol('u', real=True)
In [3]: hash(u0)
Out[3]: 1390543152
In [4]: hash(u1)
Out[4]: -685925269
In [5]: u0 == u1
Out[5]: True
In [6]: u0 in set([u1])
Out[6]: False
In [7]: u0 in [u1]
Out[7]: True
In [8]: {u0: 1, u1: 2}
Out[8]: {u: 1, u: 2}
No wonder polys get confused about symbols. Culmination is this nonsense:
In [9]: Poly(u0, u1)
...
PolynomialError: u contains an element of the generators set
What happened here? Poly() didn't recognize that u0 == u1, which is fine,
but the next step is to verify that coefficients (u0 in this case) have no
symbols in common with the set of generators, but apparently now u0 == u1,
or at least u1 in u0 (which is true).
I was curious why u0 != u1 in the parsing algorithm of Poly(), but it uses
dict() to store monomials (generator**exp, ...) (in this case u0 != u1),
but for verification it uses .has() (which is equivalent to `in`), so now
u0 == u1.
Do you think such generators should always return the construction
variables?
It depends on the problem and user convenience. In polys I either allow
user to specify his own symbols generator (it can be a list, if the number
of required symbols is known in advance). However, more often I return
symbols (in some form, e.g. as a mapping in viete()). Or (so much hated)
Pure can be convenient (but only on the user level, internally you should
use dummy symbols). If you explain the problem you want to solve, it may
have more helpful advice (than enumeration as above).
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
