On Tuesday, September 13, 2011 9:34:13 AM UTC-7, kcrisman wrote:
>
>
>
> On Sep 13, 12:08 pm, Pong <wypo...@gmail.com> wrote:
> > y,z=var('y,z'); solve(6*x + 10*y + 15*z ==1,x,y,z) gives
> > ([{x: -5/3*y - 5/2*z + 1/6}], [1])
>
> So wacky. Definitely a bug, needless to say.
>
Yes, a bug.
>
> > ([x == -y + 3], [1])
> >
> > My questions are:
> > 1) Why the notation are different in the 2 and 3-variable case? One
> > gives x: and the other x==
> >
>
> Well, you are asking for solutions to both x *and* y, but the solve is
> really designed to solve one in terms of the other(s). I just think
> no one has pointed out this weirdness before. So you are using it in
> a way it wasn't intended. I'm not sure whether we should add the
> use, or have a warning, or both, or neither, or documentation, or...
>
The documentation is clearly wrong: it says that it accepts a list of
variables to solve for, but it may really only use the first of these as a
variable, turning the others into other arguments. That is (and this is
repeating some of what kcrisman said), when you pass a single expression
(like 6*x + 10*y + 15*z ==1) to solve, it calls the method "solve" from
sage/symbolic/expression.pyx. The arguments for this are
(self, x, multiplicities=False, solution_dict=False,
explicit_solutions=False, to_poly_solve=False)
So when you call
solve(6*x + 10*y + 15*z ==1,x,y,z)
the expression becomes "self", x becomes "x", y becomes "multiplicities",
and z becomes "solution_dict". So it thinks that you are asking for a
solution in terms of x, including multiplicities (that's the "1"), and as a
dictionary.
A workaround right now: solve a system instead:
sage: solve([6*x + 10*y + 15*z ==1, 1==1],x,y,z)
[[x == -5/2*r1 - 5/3*r2 + 1/6, y == r2, z == r1]]
("r1" and "r2" stand for arbitrary numbers.)
Maybe we should put in a check for the expression having more than one
> variable before we send it to a.solve(), or maybe it just needs that
> long-awaited rewrite... see
> http://trac.sagemath.org/sage_trac/wiki/symbolics
> for some issues with solve.
>
Some sort of check on the arguments to "solve" would seem important. Or we
can check whether len(args)>1, and if so, make sure not to pass the 2nd,
3rd, etc. variables as keyword arguments like "solution_dict". Actually, we
just shouldn't pass it to Expression.solve() in this case.
> > 3) In order to get the parameters appear in the solution, one need to
> > add a redundant equation. Shall we improve on that?
> > e.g.
> > solve([x+y==3,2*x+2*y==6],x,y)
> > [[x == -r1 + 3, y == r1]]
>
> I think this is because when you do that, now the input is multiple,
> and instead of doing Expression.solve(), it does the main solve()
> routine, which deals with this.
>
> Thoughts from others who care about "solve"? I'm not quite sure what
> the best solution is. The easiest one is making really big letters in
> the documentation that say "don't do this" and trying to catch these
> cases.
>
I like the idea of doing "solve(eqn, x, y, z, ...)". This should work
according to the documentation, and it's a useful thing to be able to do, so
we should try to fix it.
--
John
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
