#5679: solve should convert additional args to SR
----------------------------+------------------------
       Reporter:  was       |        Owner:  burcin
           Type:  defect    |       Status:  new
       Priority:  major     |    Milestone:  sage-6.4
      Component:  calculus  |   Resolution:
       Keywords:            |    Merged in:
        Authors:            |    Reviewers:
Report Upstream:  N/A       |  Work issues:
         Branch:            |       Commit:
   Dependencies:            |     Stopgaps:
----------------------------+------------------------
Description changed by rws:

Old description:

> {{{
> 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)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "/Users/anakha/.sage/sage_notebook/worksheets/admin/12/code/30.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 "/Volumes/Place/anakha/Applications/sage-3.4/local/lib/python2.5
> /site-packages/sage/calculus/equations.py",
> line 1563, in solve
>    raise TypeError, "%s is not a valid variable."%v
> TypeError: not all arguments converted during string formatting
>
> 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
> }}}

New description:

 {{{
 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
 }}}

--

--
Ticket URL: <http://trac.sagemath.org/ticket/5679#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to