[sage-devel] Re: Questions about Solve
> > 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 :) -- 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
Re: [sage-devel] Re: Questions about Solve
On Tue, Sep 13, 2011 at 10:48 AM, 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 ... (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-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 > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
[sage-devel] Re: Questions about Solve
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. -- 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
[sage-devel] Re: Questions about Solve
On 9/13/11 1:30 PM, John H Palmieri wrote: 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])"? 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 -- 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
[sage-devel] Re: Questions about Solve
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 -- 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
[sage-devel] Re: Questions about Solve
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 -- 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
[sage-devel] Re: Questions about Solve
> 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. -- 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
[sage-devel] Re: Questions about Solve
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. -- 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
[sage-devel] Re: Questions about Solve
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. On Sep 13, 9:34 am, kcrisman wrote: > On Sep 13, 12:08 pm, Pong 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) > > 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... seehttp://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 -- 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
[sage-devel] Re: Questions about Solve
On Tuesday, September 13, 2011 9:34:13 AM UTC-7, kcrisman wrote: > > > > On Sep 13, 12:08 pm, Pong 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
[sage-devel] Re: Questions about Solve
On Sep 13, 12:08 pm, Pong 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) 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 -- 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