[sage-devel] Re: Enhancing the SymbolicEquation class
Robert wrote:
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
Were these enhancement ideas placed into the trac system then? I am
interested in using them in the SAGE Newbies book when they are
available.
Thanks :-)
Ted
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On Nov 5, 2007, at 2:53 PM, Ted Kosan wrote:
Robert wrote:
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
Were these enhancement ideas placed into the trac system then? I am
interested in using them in the SAGE Newbies book when they are
available.
Thanks :-)
It is now: http://sagetrac.org/sage_trac/ticket/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
William wrote:
On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
How about replace_right instead of change_right.
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
I think I like that idea, though I would like to hear from other
people, especially Ted to see what they think.
I have been experimenting with making a subclass of SymbolicEquation
called MutableSymbolicEquation but I like this approach better because
it is simpler.
Ted
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On 10/18/07, Ted Kosan [EMAIL PROTECTED] wrote: I have been experimenting with making a subclass of SymbolicEquation called MutableSymbolicEquation but I like this approach better because it is simpler. OK. By the way, subclassing SymbolicEquation by MutableSymbolicEquation would be bad because it breaks the is a relationship that subclasses must have. In general, for any classes Foo and Bar, if we have class Foo: ... class Bar(Foo): ... Then in some conceptual sense any instance of a Bar had better be a Foo, or you'll run into all kinds of trouble. Every time I break or see this rule broken, it leads to major problems down the line. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
Willam wrote: I like all of your suggestions above. Could you please give an example fake Sage session in which you illustrate use of each of the commands you wish Sage had? Implementing the functionality should then be easy for me, Bobby, or Mike Hansen (or you). But it would be good to see an example session first to make sure your proposal makes good sense for inclusion in Sage. Here is a document that contains 2 example problems: http://sage.math.washington.edu/home/tkosan/misc/SymbolicEquation_enhancements.pdf I included the 1st problem just to show the kind of effect I am trying to achieve. The 2nd problem shows where a lcd() method in the SymbolicEquation class would be helpful: a.lcd() | 6 It also shows how I am wanting to use expand() with a SymbolicEquation object. This approach seems to work fairly well except for the fact that SymbolicEquation's _left and _right instance variables are private. If these variables were public, this would provide the functionality I need. What is the reason for them being marked private? Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
How about having instance variables lhs and rhs which are thin wrappers around _left and _right which return new SymbolicEquations. That way you can do things like this: sage: a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3 sage: a *= 6 sage: a.rhs.expand() 16*x - 13 == 11*x + 7 I would also want tab completion to work with .lhs and .rhs so that you get the completions of the _left and _right objects. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
William wrote: SymbolicEquations are immutable, i.e., if you want to do something to change an equation you should get back a new equation object. The _left and _right are private-ish, because you are *not* supposed to change them. For example, when you do: b._right = b._right.expand() in your notes, that makes me very unhappy, since you are changing something you shouldn't change. Yeah, it makes me unhappy too (in the Java community, they torture people who even think about doing things like that :-) but it was an easy way to show what I was trying to achieve. I was not planning on using that code beyond the scope of this discussion. Better would be sage: b = (an equation) sage: b.expand_right() returns a new equation got from b by expanding the right hand side. Another maybe better possibility might be to have a very general method: sage: b = an equation sage: b.change_right( new right hand side) new equation which *returns* a new equation obtained from b by modifying the right hand side. Of these two solutions, I like the more general solution better because it allows access to all of the methods in SymbolicArithemetic. However, change_right() and right() start to look like getters and setters to me and it was my understanding that getters/setters were frowned upon in Python: Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well. http://dirtsimple.org/2004/12/python-is-not-java.html So if simple attribute access is okay to do in Python, why are _right and _left private? Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On 10/17/07, Ted Kosan [EMAIL PROTECTED] wrote: So if simple attribute access is okay to do in Python, why are _right and _left private? Equations are immutable, so you should *not* be changing the internal state of equations. Actually _left and _right aren't private, they are just you should not mess with them, by convention. If they were private they would be __left and __right. In fact, they should be changed to be private. So you like the suggestion to do b.change_right(...) and b.change_left(...) each of which returns a new equation? Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). William -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote: Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. I totally agree. What is better? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On Oct 17, 2007, at 9:50 PM, William Stein wrote: On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote: Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. I totally agree. What is better? How about replace_right instead of change_right. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On Oct 17, 2007, at 6:54 PM, David Harvey wrote:
On Oct 17, 2007, at 9:50 PM, William Stein wrote:
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote:
Bobby and I don't really like
sage: a.rhs.expand()
since it's a hackish abuse of notation and it is confusing to read.
It's clever though (which is not good).
I agree with that sentiment. On the other hand, I think
sage: c = b.change_right(b.right().expand())
is a bit cumbersome.
I totally agree. What is better?
How about replace_right instead of change_right.
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
How about replace_right instead of change_right.
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
I think I like that idea, though I would like to hear from other
people, especially Ted to see what they think.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
