Questions about Solve

[Pong]

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])

while
solve(x+y==3,x,y) gives
([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==

2) What the [1] in both cases stand for ?

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]]

[kcrisman]

On Sep 13, 12:08 pm, Pong <wypon...@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.

> ([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...

> 2) What the [1] in both cases stand for ?

Compare:

sage: a = x+y==3
sage: type(a)
<type 'sage.symbolic.expression.Expression'>
sage: a.solve(x,y)

([x == -y + 3], [1])

sage: a.solve(x,False)

[x == -y + 3]

sage: a.solve(x,True)

([x == -y + 3], [1])

So we are giving a non-False input to the second argument (whether we
should get multiplicities) and so we get a multiplicity of 1. Which
doesn't really make sense anyway.

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.

> 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.

- kcrisman

[John H Palmieri]

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

[Pong]

Thanks for the reply. However, I'm not so sure about the intention
part of the comment

I got the solve(x+y==3, x,y), i.e. asking solve for more than one
variables strict from the current documentation (solve? )
except I dropped the redundant equation 2x+2y==6.

Why don't solve just call the main solve() routine? but calling
Expression.solve() instead.

I think solve(x+y==3,x,y) should give

[[x == -r1 + 3, y == r1]]

while solve(x+y==3,y,x) should give

[[y == -r2 + 3, x == r2]]

Currently these can be achieved by add a redundant equation, e.g. 1==1
to the list.

> long-awaited rewrite... seehttp://trac.sagemath.org/sage_trac/wiki/symbolics

[kcrisman]

Okay, it turns out that this is the explanation for all the weirdness
at #10750, which I hadn't bothered to figure out before. I'm updating
that ticket now.

[Jason Grout]

On 9/13/11 12:00 PM, Pong wrote:
> Thanks for the reply. However, I'm not so sure about the intention
> part of the comment
>
> I got the solve(x+y==3, x,y), i.e. asking solve for more than one
> variables strict from the current documentation (solve? )
> except I dropped the redundant equation 2x+2y==6.
>
> Why don't solve just call the main solve() routine? but calling
> Expression.solve() instead.
>
> I think solve(x+y==3,x,y) should give
> [[x == -r1 + 3, y == r1]]
>
> while solve(x+y==3,y,x) should give
>
> [[y == -r2 + 3, x == r2]]
>
> Currently these can be achieved by add a redundant equation, e.g. 1==1
> to the list.

The problem is that two different methods are used, depending on if you
give one equation or multiple equations. If you give one equation, then
having multiple variables is not handled correctly.

Personally, I'm in favor of deprecating the solve(eq, x,y) or solve(list
of equations, x,y,z) syntax, and would prefer that the variables be
specified as a list:

solve(eq, [x,y]) or
solve(list of equations, [x,y,z])

Note that currently, solve(list of equations, [x,y,z]) works, and
internally, solve(list of equations, x,y,z) is converted to solve(list
of equations, (x,y,z)) anyway.

Thanks,

Jason

P.S. I wish we had keyword-only arguments
(http://www.python.org/dev/peps/pep-3102/), so that we could clearly
distinguish between the variables and optional keyword parameters, but
alas, we have to wait until we migrate to python3 since
http://bugs.python.org/issue1745 didn't get into python 2.7.

[kcrisman]

> Personally, I'm in favor of deprecating the solve(eq, x,y) or solve(list
> of equations, x,y,z) syntax, and would prefer that the variables be
> specified as a list:

Backwards-incompatible, hence fodder for the mythical Sage 5.0 ...

> solve(eq, [x,y]) or
> solve(list of equations, [x,y,z])

Though I should point out, in fairness, that Maxima requires this -
see http://maxima.sourceforge.net/docs/manual/en/maxima_20.html#IDX850
- so maybe we were wrong.

> P.S. I wish we had keyword-only arguments
> (http://www.python.org/dev/peps/pep-3102/), so that we could clearly

Huh, that is interesting.

[Jason Grout]

On 9/13/11 12:48 PM, kcrisman wrote:
>> Personally, I'm in favor of deprecating the solve(eq, x,y) or solve(list
>> of equations, x,y,z) syntax, and would prefer that the variables be
>> specified as a list:
>
> Backwards-incompatible, hence fodder for the mythical Sage 5.0 ...

the deprecation could go in now, though.

>
>> solve(eq, [x,y]) or
>> solve(list of equations, [x,y,z])
>
> Though I should point out, in fairness, that Maxima requires this -
> see http://maxima.sourceforge.net/docs/manual/en/maxima_20.html#IDX850
> - so maybe we were wrong.

So does mathematica: http://reference.wolfram.com/mathematica/ref/Solve.html

and maple: http://www.maplesoft.com/support/help/Maple/view.aspx?path=solve

Jason

[John H Palmieri]

On Tuesday, September 13, 2011 11:09:41 AM UTC-7, jason wrote:

On 9/13/11 12:48 PM, kcrisman wrote:
>> Personally, I'm in favor of deprecating the solve(eq, x,y) or solve(list
>> of equations, x,y,z) syntax, and would prefer that the variables be
>> specified as a list:
>
> Backwards-incompatible, hence fodder for the mythical Sage 5.0 ...

the deprecation could go in now, though.

Why deprecate "solve(eq, x, y)"?  Why not just handle both "solve(eq, x, y)" and "solve(eq, [x, y])"?

--
John

[Jason Grout]

We could, just like we handle both now when we have multiple equations.
Again, my personal preference is to pass the variables as a list,
though. It's cleaner, in that it groups the variables together and
separates them from the other solve arguments.

Thanks,

Jason

[William Stein]

On Tue, Sep 13, 2011 at 10:48 AM, kcrisman <kcri...@gmail.com> wrote:
>> Personally, I'm in favor of deprecating the solve(eq, x,y) or solve(list
>> of equations, x,y,z) syntax, and would prefer that the variables be
>> specified as a list:
>
> Backwards-incompatible, hence fodder for the mythical Sage 5.0 ...

(Aside, that has nothing to do with this particular solve issue.)

We deprecate after one year. I think deprecation should have nothing
to do with "sage 5.0". The policy, which we agreed on long ago is
deprecation after one year (minimum), except when there is a
compelling argument otherwise (e.g., combinat's pickles).

-- William

>
>> solve(eq, [x,y]) or
>> solve(list of equations, [x,y,z])
>
> Though I should point out, in fairness, that Maxima requires this -
> see http://maxima.sourceforge.net/docs/manual/en/maxima_20.html#IDX850
> - so maybe we were wrong.
>
>> P.S. I wish we had keyword-only arguments
>> (http://www.python.org/dev/peps/pep-3102/), so that we could clearly
>
> Huh, that is interesting.
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[kcrisman]

> > Backwards-incompatible, hence fodder for the mythical Sage 5.0 ...

> We deprecate after one year.  I think deprecation should have nothing
> to do with "sage 5.0".  The policy, which we agreed on long ago is

Sometimes we've talked about "1 year + next (major) version". My
point was that 5.0 seems to eternally be one year off :)