Opened 10 years ago
Last modified 4 years ago
#5679 new defect
solve should convert additional args to SR
Reported by: | was | Owned by: | burcin |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | calculus | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Some code that used to work in sage-3.0.6 (or something close like 3.0.3), now break with this error message: >>> R.<x0,x1,x2> = PolynomialRing(RR, 3) >>> solve([symbolic_expression(x0) == 0], x0, x1, x2) TypeError: not all arguments converted during string formatting BUT: sage: solve([symbolic_expression(x0) == 0], SR(x0), SR(x1), SR(x2)) ([{x0: 0}], [1]) The printing problem is due to the fact that Polynomials have an implicit conversion to sequence types triggered by this code: try: variables = tuple(args[0]) except TypeError: variables = args near the start of solve(), (Hint: tuple(args[0]) works if the first variable is a PolynomialElement and thus the rest of the vars are ignored and you get the bogus ((1.0000000, x0),) tuple as variables) If that is fixed, then you get this message which does not help much more: >>> R.<x0,x1,x2> = PolynomialRing(RR, 3) >>> solve([symbolic_expression(x0) == 0], x0, x1, x2) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/anakha/.sage/sage_notebook/worksheets/admin/12/code/55.py", line 8, in <module> solve(x0 == _sage_const_0 , x0, x1, x2) File "/Volumes/Place/anakha/Applications/sage/local/lib/python2.5/site-packages/SQLAlchemy-0.4.6-py2.5.egg/", line 1, in <module> File "/Users/anakha/.sage/sage_notebook/worksheets/admin/12/code/54.py", line 22, in solve raise TypeError, "%s is not a valid variable."%v TypeError: x0 is not a valid variable. Furthermore, if you disable the type checking that is done on the input variables, then it works as before: >>> R.<x0,x1,x2> = PolynomialRing(RR, 3) >>> solve([symbolic_expression(x0) == 0], x0, x1, x2) [[x0 == 0, x1 == r10, x2 == r9]] I don't think killing the typecheck is the way to go, but maybe extending it to cover the polynomial elements. Or maybe another better way to do this has come up. Arnaud
Change History (7)
comment:1 follow-up: ↓ 2 Changed 8 years ago by
- Report Upstream set to N/A
comment:2 in reply to: ↑ 1 Changed 8 years ago by
Incidentally, we never get to the
args[0]
because you are solving a single expression, so it goes toex.solve(*args)
. So maybe we should check for that... But in any case the syntax is now Weirdly,sage: solve([symbolic_expression(x0) == 0], SR(x0), SR(x1), SR(x2)) ([x0 == 0], [1])
These (tangential) things are both addressed at #10750, as it turns out.
comment:3 Changed 6 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:4 Changed 5 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:5 Changed 5 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:6 Changed 5 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:7 Changed 4 years ago by
- Description modified (diff)
- Summary changed from fix a bug in solve and polynomial generators to solve should convert additional args to SR
Note: See
TracTickets for help on using
tickets.
In Sage 4.6.2: {{[ sage: f = symbolic_expression(x0) == 0 sage: f.solve(x0)
TypeError?: x0 is not a valid variable. sage: f.solve(symbolic_expression(x0)) [x0 == 0] }}}
This is because
So I guess one could check whether SR(x) is a symbol?
Incidentally, we never get to the
args[0]
because you are solving a single expression, so it goes toex.solve(*args)
. So maybe we should check for that... But in any case the syntax is nowwhich does raise the error in question.
But
Weirdly,