24 views

Skip to first unread message

Sep 13, 2011, 12:08:33 PM9/13/11

to sage-devel

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

([{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]]

Sep 13, 2011, 12:34:13 PM9/13/11

to sage-devel

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

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

>

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 ?

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

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

Sep 13, 2011, 12:50:10 PM9/13/11

to sage-...@googlegroups.com

On Tuesday, September 13, 2011 9:34:13 AM UTC-7, kcrisman wrote:

Yes, a bug.

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)

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.

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

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

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

Sep 13, 2011, 1:00:19 PM9/13/11

to sage-devel

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

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

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.

Sep 13, 2011, 1:05:44 PM9/13/11

to sage-devel

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.

at #10750, which I hadn't bothered to figure out before. I'm updating

that ticket now.

Sep 13, 2011, 1:24:19 PM9/13/11

to sage-...@googlegroups.com

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.

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

Sep 13, 2011, 1:48:43 PM9/13/11

to sage-devel

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

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

Sep 13, 2011, 2:09:41 PM9/13/11

to sage-...@googlegroups.com

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

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

Sep 13, 2011, 2:30:38 PM9/13/11

to sage-...@googlegroups.com

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

--

John

Sep 13, 2011, 2:37:18 PM9/13/11

to sage-...@googlegroups.com

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

Sep 14, 2011, 2:38:35 AM9/14/11

to sage-...@googlegroups.com

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

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

Sep 14, 2011, 8:40:52 AM9/14/11

to sage-devel

> > 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
> to do with "sage 5.0". The policy, which we agreed on long ago is

point was that 5.0 seems to eternally be one year off :)

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu