[sage-devel] Re: Literal matrix syntax
Currently one must write sage: matrix([[1, 2], [3, 4]]) [1 2] [3 4] sage: matrix([[1, 2], [3, 4]]) * matrix([[5, 6], [7, 8]]) [19 22] [43 50] Well, one can avoid writing to much square brackets by doing : sage: matrix(2, [1,2,3,4]) [1 2] [3 4] sage: matrix(2, [1, 2, 3, 4]]) * matrix(2, [5, 6, 7, 8]) [19 22] [43 50] SL -- 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: Literal matrix syntax
No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) Dima -- 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: Literal matrix syntax
2012/1/26 Dima Pasechnik dimp...@gmail.com: No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) How about [1,2,3;] for matrix([[1,2,3]])? This problem and solution are similar to (1,) for a 1-tuple in Python. Dima -- 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 -- 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: Literal matrix syntax
On Thursday, January 26, 2012 5:37:14 PM UTC+8, Marco Streng wrote: 2012/1/26 Dima Pasechnik dim...@gmail.com: No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) How about [1,2,3;] for matrix([[1,2,3]])? This problem and solution are similar to (1,) for a 1-tuple in Python. then, for consistency, it should be then [1,2;3,4;], i.e. end each row with ; Dima -- 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 -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 1:43 AM, Dima Pasechnik dimp...@gmail.com wrote: then, for consistency, it should be then [1,2;3,4;], i.e. end each row with ; It can be optional: In [6]: (1,2,3) Out[6]: (1, 2, 3) In [7]: (1,2,3,) Out[7]: (1, 2, 3) --Mike -- 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: Literal matrix syntax
Python does (1,) but allows and encourages (1, 2) rather than (1, 2,), so IMO we should do [1, 2;] but allow and encourage [1, 2; 3, 4] rather than [1, 2; 3, 4;]. Great idea btw, I like this. This would make it as easy to enter matrices quickly into Sage as it is in Mathematica, MATLAB, etc. I agree with Marco that the ring of [a, b; c, d]should agree with whatever matrix([[a, b], [c, d]]) does, and in fact should just preparse directly into that (as the current patch does, if I'm not mistaken). See also http://trac.sagemath.org/sage_trac/ticket/11699 which implements similar behavior but as string inputs to matrix() rather than in the preparser. IMO this is not very useful unless we combine it with preparsing, because the main advantage of this input format is its brevity, which is a big plus. -Keshav Join us in #sagemath on irc.freenode.net ! -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 1:37 AM, Marco Streng marco.str...@gmail.com wrote: 2012/1/26 Dima Pasechnik dimp...@gmail.com: No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) How about [1,2,3;] for matrix([[1,2,3]])? This problem and solution are similar to (1,) for a 1-tuple in Python. Yes, exactly, that's in part what I meant about trailing semicolons. The trailing one is optional when there's more than one row (just like tuples). As for global defaults, it's nice for both examples and debugging for there to be as little global state as possible, and someone who wants RDF for reals probably wants CDF for complexes. The consistency argument is a good one, but changing matrix(...) would be much more invasive, and both defaults have their pros and cons, so the simpler syntax could be used for the simpler (i.e. more basic user that doesn't want to care about baserings but just wants to slice and dice some matrices) default. - Robert -- 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: Literal matrix syntax
As for global defaults, it's nice for both examples and debugging for there to be as little global state as possible, and someone who wants RDF for reals probably wants CDF for complexes. The consistency argument is a good one, but changing matrix(...) would be much more invasive, and both defaults have their pros and cons, so the simpler syntax could be used for the simpler (i.e. more basic user that doesn't want to care about baserings but just wants to slice and dice some matrices) default. I agree that having very little global state is good, but right now I don't think that Sage is succeeding very well in our mission to provide a viable alternative to Matlab. I would like to see more users to Sage who care about floating point linear algebra, and I think it's worth having some global state if we can attract such people by making it easier to create matrices with floats. David -- 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: Literal matrix syntax
On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote: As for global defaults, it's nice for both examples and debugging for there to be as little global state as possible, and someone who wants RDF for reals probably wants CDF for complexes. The consistency argument is a good one, but changing matrix(...) would be much more invasive, and both defaults have their pros and cons, so the simpler syntax could be used for the simpler (i.e. more basic user that doesn't want to care about baserings but just wants to slice and dice some matrices) default. I agree that having very little global state is good, but right now I don't think that Sage is succeeding very well in our mission to provide a viable alternative to Matlab. I would like to see more users to Sage who care about floating point linear algebra, and I think it's worth having some global state if we can attract such people by making it easier to create matrices with floats. David Axiom associates the target type of the input so you type a:Matrix(Integer) := [[1]] or b:Matrix(Float) := [[1.1]] or for larger values c:Matrix(Integer) := [[1,2,3],[4,5,6]] d:Matrix(Float) := [[1.1,2.1,3.1],[4.1,5.1,6.1]] Tim Daly -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 2:16 AM, daly d...@axiom-developer.org wrote: On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote: As for global defaults, it's nice for both examples and debugging for there to be as little global state as possible, and someone who wants RDF for reals probably wants CDF for complexes. The consistency argument is a good one, but changing matrix(...) would be much more invasive, and both defaults have their pros and cons, so the simpler syntax could be used for the simpler (i.e. more basic user that doesn't want to care about baserings but just wants to slice and dice some matrices) default. I agree that having very little global state is good, but right now I don't think that Sage is succeeding very well in our mission to provide a viable alternative to Matlab. I would like to see more users to Sage who care about floating point linear algebra, and I think it's worth having some global state if we can attract such people by making it easier to create matrices with floats. David Axiom associates the target type of the input so you type a:Matrix(Integer) := [[1]] or b:Matrix(Float) := [[1.1]] or for larger values c:Matrix(Integer) := [[1,2,3],[4,5,6]] d:Matrix(Float) := [[1.1,2.1,3.1],[4.1,5.1,6.1]] One can always make it explicit, e.g. matrix(QQ, [[1,2],[3,4]]) or (hypothetically) [1, 2; 3, 4; base_ring=QQ]; the question is about what to do in the implicit case. IMHO, the current default doesn't suit many users well, in particular it does disservice to those users who wouldn't even think to specify the basering. - Robert -- 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: Literal matrix syntax
Matlab users are spoiled, as everything is a matrix of floats there. Do you know that 0==0.0 and 0==[0] in Matlab? Going this way, we will end up renaming binomial() to nchoosek(), and creating a Matlab clone :-) -- 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: Literal matrix syntax
On Thu, 2012-01-26 at 02:24 -0800, Robert Bradshaw wrote: On Thu, Jan 26, 2012 at 2:16 AM, daly d...@axiom-developer.org wrote: On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote: As for global defaults, it's nice for both examples and debugging for there to be as little global state as possible, and someone who wants RDF for reals probably wants CDF for complexes. The consistency argument is a good one, but changing matrix(...) would be much more invasive, and both defaults have their pros and cons, so the simpler syntax could be used for the simpler (i.e. more basic user that doesn't want to care about baserings but just wants to slice and dice some matrices) default. I agree that having very little global state is good, but right now I don't think that Sage is succeeding very well in our mission to provide a viable alternative to Matlab. I would like to see more users to Sage who care about floating point linear algebra, and I think it's worth having some global state if we can attract such people by making it easier to create matrices with floats. David Axiom associates the target type of the input so you type a:Matrix(Integer) := [[1]] or b:Matrix(Float) := [[1.1]] or for larger values c:Matrix(Integer) := [[1,2,3],[4,5,6]] d:Matrix(Float) := [[1.1,2.1,3.1],[4.1,5.1,6.1]] One can always make it explicit, e.g. matrix(QQ, [[1,2],[3,4]]) or (hypothetically) [1, 2; 3, 4; base_ring=QQ]; the question is about what to do in the implicit case. IMHO, the current default doesn't suit many users well, in particular it does disservice to those users who wouldn't even think to specify the basering. Sorry, I was unclear. Axiom associates the type with the target, so a:= [[1,2,3],[4,5,6]] == List List Integer b:Matrix(Float)== Type: Void c:Matrix(Integer) == Type: Void d:Matrix(RomanNumeral) == Type: Void e:Matrix(Fraction(Integer) == Type: Void b:=a + 1.0 2.0 3.0 + | | + 4.0 5.0 6.0 + == Type: Matrix Float so the line b:Matrix(Float) means that the symbol 'b' expects to hold something of the type Matrix(Float). The assignment b:=a assigned a List(List(Integer)) to the type of 'b' which causes an implicit coerce to the target type. c:=a + 1 2 3 + | | + 4 5 6 + == Type: Matrix Integer Working from the same List(List(Integer)) we get a different base ring of the matrix. d:=a + I II III+ | | + IV V VI + == Type: Matrix RomanNumeral I don't know how Sage handles the 'd:=a' case above. e:=a + 1 2 3 + | | + 4 5 6 + == Type: Matrix Fraction Integer Notice the output of the assignment 'c:=a' and 'e:=a' APPEAR to be the same but this is only because the denominator is 1. e:=[[1/2, 1/3, 1/4],[1/5,1/6,1/7]] + 1 1 1+ | - - -| | 2 3 4| | | | 1 1 1| | - - -| + 5 6 7+ It seems that if you have many possible base rings (which Axiom has) you need either an explicit coerce when the object is created or you need to know how to coerce a general input type (in this case, list) into the target type. So I am suggesting that a clean syntax is possible if the base ring is associated with the target symbol, not with the input tokens. Tim Daly -- 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: Literal matrix syntax
So I am suggesting that a clean syntax is possible if the base ring is associated with the target symbol, not with the input tokens. Apprently in Axiom you can statically type variable names, whereas in Python a variable is dynamically typed: you can't specify that a should hold an Integer for example. sage: a = 4; type(a) type 'sage.rings.integer.Integer' sage: a = 4/3; type(a) type 'sage.rings.rational.Rational' David -- 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: Literal matrix syntax
Hi all! On 26 Jan., 10:37, Marco Streng marco.str...@gmail.com wrote: 2012/1/26 Dima Pasechnik dimp...@gmail.com: No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) How about [1,2,3;] for matrix([[1,2,3]])? This problem and solution are similar to (1,) for a 1-tuple in Python. Robert was referring to some very long thread in his original post, and I think it already contains an extensive discussion about the [1,2,3;] syntax. Cheers, Simon -- 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: Literal matrix syntax
On Thu, 2012-01-26 at 03:05 -0800, David Roe wrote: So I am suggesting that a clean syntax is possible if the base ring is associated with the target symbol, not with the input tokens. Apprently in Axiom you can statically type variable names, whereas in Python a variable is dynamically typed: you can't specify that a should hold an Integer for example. sage: a = 4; type(a) type 'sage.rings.integer.Integer' sage: a = 4/3; type(a) type 'sage.rings.rational.Rational' David The fact that the type is different seems to imply that Sage must manipulate the input somehow. Python does not know about rings. How is this done? Could the processing allow you to specify the type of the target with a particular syntax? All you need to do is keep a hash table of the specified target type. If the symbol is not found then do the usual process else use the specified target type. Tim Daly -- 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: Literal matrix syntax
What would Matlab users think of having to learn the habit of putting . behind their integers in Sage, e.g.? sage: matrix([[1.,2],[3,4]]).base_ring() Real Field with 53 bits of precision sage: matrix([[1/1,2],[3,4]]).base_ring() Rational Field This would be a possible warning to engineers: Make sure numbers contain . even if they are integers, e.g., type 2. instead of 2 when you want the number 2. The reason: Sage is used by many kinds of users. For example, if you type an integer, then Sage may assume that you are interested only in integers and that you want (slow) exact arithmetic. Sage will even reply False to [1,2;3,4].is_invertible(). Typing a . behind your integers makes them into nice fast floating point numbers, so that [1.,2;3,4].is_invertible() does return True as expected. Do we have good introduction to Sage for Matlab users, introduction to Sage for Maple users, etc.? Those would be a good place for warnings of this form and good habits. It would be hard to explain in the documentation when to use [[1,2;3,4]] versus matrix([[1,2],[3,4]]). And if we want a default for [1,2;3,4], would it be QQ or RDF? QQ may become inefficient as numbers become large, but how do we know whether users want exact arithmetic or not? Also, maybe the docstring of is_invertible could have a big warning so that people use is_singular instead if they are not interested in ZZ, but only in fields. -- 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: Literal matrix syntax
On 1/26/12 5:30 AM, Marco Streng wrote: What would Matlab users think of having to learn the habit of putting . behind their integers in Sage, e.g.? sage: matrix([[1.,2],[3,4]]).base_ring() Real Field with 53 bits of precision sage: matrix([[1/1,2],[3,4]]).base_ring() Rational Field This would be a possible warning to engineers: Make sure numbers contain . even if they are integers, e.g., type 2. instead of 2 when you want the number 2. The reason: Sage is used by many kinds of users. For example, if you type an integer, then Sage may assume that you are interested only in integers and that you want (slow) exact arithmetic. Sage will even reply False to [1,2;3,4].is_invertible(). Typing a . behind your integers makes them into nice fast floating point numbers, so that [1.,2;3,4].is_invertible() does return True as expected. That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Do we have good introduction to Sage for Matlab users, introduction to Sage for Maple users, etc.? Those would be a good place for warnings of this form and good habits. Good point. We should have documentation like this, but don't. 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
Re: [sage-devel] Re: Literal matrix syntax
2012/1/26 Jason Grout jason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. -- 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: Literal matrix syntax
On 1/26/12 7:54 AM, Marco Streng wrote: 2012/1/26 Jason Groutjason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. 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
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 6:12 AM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 7:54 AM, Marco Streng wrote: 2012/1/26 Jason Groutjason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. For example, with RDF the largest allowed number is actually pretty tiny: sage: a = 10.0^1000; a 1.00e1000 sage: type(a) type 'sage.rings.real_mpfr.RealNumber' sage: float(a) inf I've been hit by this many times when developing algorithms. For example, for some exact linear algebra work I was doing with Clement Pernet, we developed an algorithm, and it wasn't possible to compute the relevant bounds for big input using machine doubles, i.e., using RDF. I found it easy to implement that part of the algorithm, because Sage has mpfr (i.e., RR), but Clement had to redesign that whole part of the algorithm in order to properly implement it in Linbox, because Linbox does (or didn't) depend on mpfr. -- William 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 -- 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
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 2:51 AM, daly d...@axiom-developer.org wrote: [...lots of axiom examples and Sage questions...] Sage, like Axiom, distinguishes between Integers and Rationals with a trivial denominator, has a strong notion of a basering (for matrices, polynomials), etc. You may want to look up coercion and the preparser to answer you questions about how Sage works, but that's getting somewhat offtrack. So I am suggesting that a clean syntax is possible if the base ring is associated with the target symbol, not with the input tokens. That works for Axiom, but for Sage it would this be a large departure from Python, and then we'd also need to invent a syntax for typing anonymous sub-expressions, at which point you might as well use matrix(R, ...). - Robert -- 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: Literal matrix syntax
To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. Why? Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. Why? On Thu, Jan 26, 2012 at 6:12 AM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 7:54 AM, Marco Streng wrote: 2012/1/26 Jason Groutjason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. 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 -- 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: Literal matrix syntax
Hi Robert, On 26 Jan., 19:13, Robert Bradshaw rober...@math.washington.edu wrote: Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [X ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. Why? When I create matrices, then I usually do so in a program. Hence, syntactical sugar such as the suggested notion simply does not matter for me. First, I create a matrix space, and then construct matrices by passing lists (or lists of lists) of elements to the matrix space. I find this rather practical. Personally, I find the syntax [1,2;3,4] horrible. But I wouldn't be so mean to prevent other people from using it. Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. None of the above. Real mathematicians and real programmers are providing the base ring explicitly :-) Cheers, Simon -- 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: Literal matrix syntax
Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ X ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. Why? Short, intuitive, clear, coincides with gp notation. Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ X ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. Why? I think strongly that there should be no difference between [a,b; c,d] and matrix([[a,b],[c,d]]). Otherwise the difference will have to be explained over and over again. I don't personally know enough to say anything about RR - RDF for matrices, so no opinion on that. ZZ - QQ for matrix will likely break some people's existing code. It also means extra pain for me personally. What does R - Frac(R) mean when it is hard to decide whether R is a domain? -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 10:13 AM, Robert Bradshaw rober...@math.washington.edu wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [x] Yes, I love this syntax! It would be make life better for me Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [x] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. It would be nice to be able to specify a type. Perhaps R.[1,2,3;2,3,4] - Matrix(R,[[1,2,3],[2,3,4]]) or perhaps even R[1,2,3;2,3,4] On Thu, Jan 26, 2012 at 6:12 AM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 7:54 AM, Marco Streng wrote: 2012/1/26 Jason Groutjason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. 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 -- 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 -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 10:13 AM, Robert Bradshaw rober...@math.washington.edu wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [X ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. Why? Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [X] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. I'm more for *consistency* between the matrix command the matrix notation and for fixing any issues with matrices over ZZ that make them bad. -- William Why? On Thu, Jan 26, 2012 at 6:12 AM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 7:54 AM, Marco Streng wrote: 2012/1/26 Jason Groutjason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. 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 -- 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: Literal matrix syntax
On 1/26/12 1:57 PM, Tom Boothby wrote: It would be nice to be able to specify a type. Perhaps R.[1,2,3;2,3,4] - Matrix(R,[[1,2,3],[2,3,4]]) or perhaps even R[1,2,3;2,3,4] Another option would be: [QQ: 1,2,3; 4,5,6] or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. As a side note, I guess if QQ^2 gives the vector space over QQ, then QQ^(2,3) should give the matrix space over QQ of 2x3 matrices (I don't think it does now, but that would be nice if it did). 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: Literal matrix syntax
Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [x ] Yes, I love this syntax! It would be make life better for me and my students. Why? This makes it easier to win over people used to Matlab. Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [x ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. Why? At least in most teaching uses, this is more desirable behavior. For example, in teaching echelon forms to undergraduates. -Marshall -- 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: Literal matrix syntax
On 1/26/12 2:04 PM, William Stein wrote: [X] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. That would go great in our linear algebra article or in the Sage docs ;) 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: Literal matrix syntax
On 1/26/12 12:13 PM, Robert Bradshaw wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. I waffle between Yes, and Yes with convincing. I'm trying it out now to see how I feel about it. I feel like we shouldn't extend python too much, but this syntax is very tempting. Why? Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. I should just note several areas that ZZ matrices come up short (intuitively) when you assume you are usually working over fields: sage: a=[1,2; 3,4] sage: a[0,0]=1/2 (error...) sage: a.rational_form() (error...) sage: a.rescale_row(1/2) (error...though the error message is a little more helpful and says to use with_rescaled_row...) I agree mostly with the people who say that [] and matrix() should be consistent. I've resigned myself to always declaring my ring as QQ, etc. 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
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 1:57 PM, Tom Boothby wrote: It would be nice to be able to specify a type. Perhaps R.[1,2,3;2,3,4] - Matrix(R,[[1,2,3],[2,3,4]]) or perhaps even R[1,2,3;2,3,4] Another option would be: [QQ: 1,2,3; 4,5,6] or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. My thoughts were that keyword arguments after the final semicolon would get passed as keyword arguments to the matrix constructor, so one could do [1,2,3; 4,5,6; sparse=True, base_ring=QQ, ...]. R[...] or [R: ...] aren't bad ideas either (though the former gets messy to pick out the R which may be an arbitrary expression). As a side note, I guess if QQ^2 gives the vector space over QQ, then QQ^(2,3) should give the matrix space over QQ of 2x3 matrices (I don't think it does now, but that would be nice if it did). +1 -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 12:13 PM, Robert Bradshaw wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. I waffle between Yes, and Yes with convincing. I'm trying it out now to see how I feel about it. I feel like we shouldn't extend python too much, but this syntax is very tempting. Why? Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. I should just note several areas that ZZ matrices come up short (intuitively) when you assume you are usually working over fields: sage: a=[1,2; 3,4] sage: a[0,0]=1/2 (error...) sage: a.rational_form() (error...) sage: a.rescale_row(1/2) (error...though the error message is a little more helpful and says to use with_rescaled_row...) I agree mostly with the people who say that [] and matrix() should be consistent. I've resigned myself to always declaring my ring as QQ, etc. I would be *more* OK with changing the default base ring in matrix to be the fraction field. William 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 -- 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
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout jason-s...@creativetrax.com wrote: I waffle between Yes, and Yes with convincing. I'm trying it out now to see how I feel about it. I feel like we shouldn't extend python too much, but this syntax is very tempting. BTW, at the upcoming pydata workshop: http://pydataworkshop.eventbrite.com/ I'm organizing a panel discussion with Guido and other core developers precisely to discuss possible improvements to the language that would benefit scientific users. I haven't put any formal announcement yet (will try to do so in the next couple of days), but if any of you will be near the Mountain View googleplex on Friday March 2, keep this in mind. Once I put out a formal announcement we'll set up a signup list for people to attend. I hope that in that panel we'll be able to discuss issues such as this one (I also would like python to expose native division into the rationals à la Sage, so that the main *semantic* difference between sage and python could be removed). Cheers, f -- 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: Literal matrix syntax
On Jan 26, 3:19 pm, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 12:13 PM, Robert Bradshaw wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. I waffle between Yes, and Yes with convincing. I'm trying it out now to see how I feel about it. I feel like we shouldn't extend python too much, but this syntax is very tempting. Why *not* use it? Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. I should just note several areas that ZZ matrices come up short (intuitively) when you assume you are usually working over fields: sage: a=[1,2; 3,4] sage: a[0,0]=1/2 (error...) sage: a.rational_form() (error...) sage: a.rescale_row(1/2) (error...though the error message is a little more helpful and says to use with_rescaled_row...) But we've at least done some work with this, dating back to some of my first patches, and the great rref() which you guys all implemented. So I don't know that we should change this behavior, as convenient as it would be for my purposes. -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 1:33 PM, kcrisman kcris...@gmail.com wrote: On Jan 26, 3:19 pm, Jason Grout jason-s...@creativetrax.com wrote: On 1/26/12 12:13 PM, Robert Bradshaw wrote: To get a quick sense of what people think about this, I've decided to rephrase this as a survey. To be clear, though this coincides with Matlab syntax, the intent is not to try to make Sage a Matlab clone, rather it is to add a missing feature to Sage. Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. I waffle between Yes, and Yes with convincing. I'm trying it out now to see how I feel about it. I feel like we shouldn't extend python too much, but this syntax is very tempting. Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. -- William Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. I should just note several areas that ZZ matrices come up short (intuitively) when you assume you are usually working over fields: sage: a=[1,2; 3,4] sage: a[0,0]=1/2 (error...) sage: a.rational_form() (error...) sage: a.rescale_row(1/2) (error...though the error message is a little more helpful and says to use with_rescaled_row...) But we've at least done some work with this, dating back to some of my first patches, and the great rref() which you guys all implemented. So I don't know that we should change this behavior, as convenient as it would be for my purposes. -- 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
Re: [sage-devel] Re: Literal matrix syntax
On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). It also risks suggesting that sage matrices behave like matlab ones, which could cause confusion. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. I consider my reason a better argument against it. Robert's implemented something *very* similar in the past, namely [a..b] for lists and (a..b) for generators and we've never had any bugs/issues/maintenance problems with it at all. Not once. But it is also a small issue that it doesn't work in normal python. William This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). It also risks suggesting that sage matrices behave like matlab ones, which could cause confusion. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. -- 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
Re: [sage-devel] Re: Literal matrix syntax
On 01/26/12 17:00, William Stein wrote: On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. I consider my reason a better argument against it. Robert's implemented something *very* similar in the past, namely [a..b] for lists and (a..b) for generators and we've never had any bugs/issues/maintenance problems with it at all. Not once. But it is also a small issue that it doesn't work in normal python. I shouldn't have said better. I started with something like more general but then backtracked once I said something about matlab matrices. -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). I'd say it's a fairly simple preparse. The only tricky part is multi-line handling in the face of iPython (where each line needs to be pre-parsed individually, and that IMHO should be handled better at a higher level where we buffer lines until we have a complete statement and then preparse them as a whole). In any case, I'm willing to maintain it for the next 5 years (which I expect will be trivial). It also risks suggesting that sage matrices behave like Matlab ones, which could cause confusion. Or suggest they behave like Pari matrices which use the same syntax, but I don't think that's any more of an issue than say integers or division in Matlab vs Sage. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. If we found such a feature useful, we probably wouldn't try to embed it into our syntax. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. I totally agree with you here, the bar for adding to the preparser should be high. I think it's a good candidate here because (1) It's easy to understand what it means (2) it's illegal Python syntax, and (3) Python doesn't even have the notion of matrices, so it's doubly clear (perhaps once you get the SyntaxError) that it's a Sage-only feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. Interesting idea, but then we'd have to detect whether the brackets were creating a list vs. acting as an index operator and prepares differently in the two situations lest we have R[...;...] - R[matrix_literal(...)] forcing [...;...] - [matrix_literal(...)], a list of one item. One also has [a, b; c, d].change_ring(R). The exact notation for specifying the basering can be deferred, though it does highlight the importance of choosing a default according to the principle of least surprise. - Robert -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). I'd say it's a fairly simple preparse. The only tricky part is multi-line handling in the face of iPython (where each line needs to be pre-parsed individually, and that IMHO should be handled better at a higher level where we buffer lines until we have a complete statement and then preparse them as a whole). In any case, I'm willing to maintain it for the next 5 years (which I expect will be trivial). It also risks suggesting that sage matrices behave like Matlab ones, which could cause confusion. Or suggest they behave like Pari matrices which use the same syntax, but I don't think that's any more of an issue than say integers or division in Matlab vs Sage. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. If we found such a feature useful, we probably wouldn't try to embed it into our syntax. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. I totally agree with you here, the bar for adding to the preparser should be high. I think it's a good candidate here because (1) It's easy to understand what it means (2) it's illegal Python syntax, and (3) Python doesn't even have the notion of matrices, so it's doubly clear (perhaps once you get the SyntaxError) that it's a Sage-only feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. Interesting idea, but then we'd have to detect whether the brackets were creating a list vs. acting as an index operator and prepares differently in the two situations lest we have R[...;...] - R[matrix_literal(...)] forcing [...;...] - [matrix_literal(...)], a list of one item. Yeah, I had my doubts about that, too. Perhaps R[[...;...]] would be better, but I'm not really happy with this either. One also has [a, b; c, d].change_ring(R). The exact notation for specifying the basering can be deferred, though it does highlight the importance of choosing a default according to the principle of least surprise. I'd like whatever notation we arrive at to be efficient. If we preparse RDF[1,2,3;4,5,6] - Matrix(RDF,[[Integer(1),Integer(2),...]]) or use [...;...].change_ring(R) then we're gonna waste a lot of time, creating useless Integers and / or computing a common parent. What of a new keyword, [1,2...;...] over R - Matrix(R,[[R(1),R(2)...],[...]]) or perhaps something like [R$1,2,3;4,5,6] or [1,2,3;4,5,6]@R I'm not particularly attached to any idea. - Robert -- 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 -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). I'd say it's a fairly simple preparse. The only tricky part is multi-line handling in the face of iPython (where each line needs to be pre-parsed individually, and that IMHO should be handled better at a higher level where we buffer lines until we have a complete statement and then preparse them as a whole). In any case, I'm willing to maintain it for the next 5 years (which I expect will be trivial). It also risks suggesting that sage matrices behave like Matlab ones, which could cause confusion. Or suggest they behave like Pari matrices which use the same syntax, but I don't think that's any more of an issue than say integers or division in Matlab vs Sage. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. If we found such a feature useful, we probably wouldn't try to embed it into our syntax. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. I totally agree with you here, the bar for adding to the preparser should be high. I think it's a good candidate here because (1) It's easy to understand what it means (2) it's illegal Python syntax, and (3) Python doesn't even have the notion of matrices, so it's doubly clear (perhaps once you get the SyntaxError) that it's a Sage-only feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. Interesting idea, but then we'd have to detect whether the brackets were creating a list vs. acting as an index operator and prepares differently in the two situations lest we have R[...;...] - R[matrix_literal(...)] forcing [...;...] - [matrix_literal(...)], a list of one item. Yeah, I had my doubts about that, too. Perhaps R[[...;...]] would be better, but I'm not really happy with this either. One also has [a, b; c, d].change_ring(R). The exact notation for specifying the basering can be deferred, though it does highlight the importance of choosing a default according to the principle of least surprise. I'd like whatever notation we arrive at to be efficient. If we preparse RDF[1,2,3;4,5,6] - Matrix(RDF,[[Integer(1),Integer(2),...]]) or use [...;...].change_ring(R) then we're gonna waste a lot of time, creating useless Integers and / or computing a common parent. I'm not extremely concerned about efficiency. These are literal matrices after all, so presumably someone's typing them in by hand. (If they're programmatically generated, construct the matrix directly or vai a better constructor if you're worried about efficiency. Conversion of ZZ to QQ is much faster than the parsing or even str - ZZ in the first place). But if the basering can be worked into the original constructor, that's a plus. It'd be nice to be able to pass arbitrary keywords into the constructor for the same reason. What of a new keyword, [1,2...;...] over R - Matrix(R,[[R(1),R(2)...],[...]]) or perhaps something like [R$1,2,3;4,5,6] or [1,2,3;4,5,6]@R I'm not particularly attached to any idea. It's much simpler (technically and conceptually) to pick out the ring if it lies entirely in the brackets. I'd go for a colon over # or @. - Robert -- 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
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). I'd say it's a fairly simple preparse. The only tricky part is multi-line handling in the face of iPython (where each line needs to be pre-parsed individually, and that IMHO should be handled better at a higher level where we buffer lines until we have a complete statement and then preparse them as a whole). In any case, I'm willing to maintain it for the next 5 years (which I expect will be trivial). It also risks suggesting that sage matrices behave like Matlab ones, which could cause confusion. Or suggest they behave like Pari matrices which use the same syntax, but I don't think that's any more of an issue than say integers or division in Matlab vs Sage. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. If we found such a feature useful, we probably wouldn't try to embed it into our syntax. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. I totally agree with you here, the bar for adding to the preparser should be high. I think it's a good candidate here because (1) It's easy to understand what it means (2) it's illegal Python syntax, and (3) Python doesn't even have the notion of matrices, so it's doubly clear (perhaps once you get the SyntaxError) that it's a Sage-only feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. Interesting idea, but then we'd have to detect whether the brackets were creating a list vs. acting as an index operator and prepares differently in the two situations lest we have R[...;...] - R[matrix_literal(...)] forcing [...;...] - [matrix_literal(...)], a list of one item. Yeah, I had my doubts about that, too. Perhaps R[[...;...]] would be better, but I'm not really happy with this either. One also has [a, b; c, d].change_ring(R). The exact notation for specifying the basering can be deferred, though it does highlight the importance of choosing a default according to the principle of least surprise. I'd like whatever notation we arrive at to be efficient. If we preparse RDF[1,2,3;4,5,6] - Matrix(RDF,[[Integer(1),Integer(2),...]]) or use [...;...].change_ring(R) then we're gonna waste a lot of time, creating useless Integers and / or computing a common parent. I'm not extremely concerned about efficiency. These are literal matrices after all, so presumably someone's typing them in by hand. Fair enough. (If they're programmatically generated, construct the matrix directly or vai a better constructor if you're worried about efficiency. Conversion of ZZ to QQ is much faster than the parsing or even str - ZZ in the first place). But if the basering can be worked into the original constructor, that's a plus. It'd be nice to be able to pass arbitrary keywords into the constructor for the same reason. What of a new keyword, [1,2...;...] over R - Matrix(R,[[R(1),R(2)...],[...]]) or perhaps something like [R$1,2,3;4,5,6] or [1,2,3;4,5,6]@R I'm not particularly attached to any idea. It's much simpler (technically and conceptually) to pick out the ring if it lies entirely in the brackets. I'd go for a colon over # or @. Another issue: do we allow [1..10; 10..20]? I can't seem to construct matrices with matrix entries (this is not
Re: [sage-devel] Re: Literal matrix syntax
On Thu, Jan 26, 2012 at 3:51 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/26/12 16:36, William Stein wrote: Why *not* use it? The standard argument against preparser stuff like this is that you have to be careful to not use it when writing .py code for the Sage core library. But at least this matrix notation will always result in a SyntaxError if used in Python code. A better reason is that, once implemented, someone has to maintain it forever. This is a fairly invasive preparse, and will likely cause more than a few bugs (see implicit multiplication for examples). I'd say it's a fairly simple preparse. The only tricky part is multi-line handling in the face of iPython (where each line needs to be pre-parsed individually, and that IMHO should be handled better at a higher level where we buffer lines until we have a complete statement and then preparse them as a whole). In any case, I'm willing to maintain it for the next 5 years (which I expect will be trivial). It also risks suggesting that sage matrices behave like Matlab ones, which could cause confusion. Or suggest they behave like Pari matrices which use the same syntax, but I don't think that's any more of an issue than say integers or division in Matlab vs Sage. Furthermore, some preparses are mutually exclusive: if you implement this one now, and Mathematica comes out with a killer feature a year from now using similar syntax ([do; my; homework; for; me;]), you can't preparse that. If we found such a feature useful, we probably wouldn't try to embed it into our syntax. Some preparses are worth it, obviously; I wouldn't throw them both out because they might conflict with one another. But the bar for inclusion should be pretty high. I totally agree with you here, the bar for adding to the preparser should be high. I think it's a good candidate here because (1) It's easy to understand what it means (2) it's illegal Python syntax, and (3) Python doesn't even have the notion of matrices, so it's doubly clear (perhaps once you get the SyntaxError) that it's a Sage-only feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout jason-s...@creativetrax.com wrote: Another option would be: [QQ: 1,2,3; 4,5,6] QQ:1 is a slice... or, as Robert suggests: [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is another element. assignments aren't literals... but I don't like this. My thought for R[1,2,3;4,5,6] is that just as we preparse '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' where Ring.__getitem__(self, x) could have a fast option for matrix literals - matrices. Interesting idea, but then we'd have to detect whether the brackets were creating a list vs. acting as an index operator and prepares differently in the two situations lest we have R[...;...] - R[matrix_literal(...)] forcing [...;...] - [matrix_literal(...)], a list of one item. Yeah, I had my doubts about that, too. Perhaps R[[...;...]] would be better, but I'm not really happy with this either. One also has [a, b; c, d].change_ring(R). The exact notation for specifying the basering can be deferred, though it does highlight the importance of choosing a default according to the principle of least surprise. I'd like whatever notation we arrive at to be efficient. If we preparse RDF[1,2,3;4,5,6] - Matrix(RDF,[[Integer(1),Integer(2),...]]) or use [...;...].change_ring(R) then we're gonna waste a lot of time, creating useless Integers and / or computing a common parent. I'm not extremely concerned about efficiency. These are literal matrices after all, so presumably someone's typing them in by hand. Fair enough. (If they're programmatically generated, construct the matrix directly or vai a better constructor if you're worried about efficiency. Conversion of ZZ to QQ is much faster than the parsing or even str - ZZ in the first place). But if the basering can be worked into the original constructor, that's a plus. It'd be nice to be able to pass arbitrary keywords into the constructor for the same reason. What of a new keyword, [1,2...;...] over R - Matrix(R,[[R(1),R(2)...],[...]]) or perhaps something like [R$1,2,3;4,5,6] or [1,2,3;4,5,6]@R I'm not particularly attached to any idea. It's much simpler (technically and conceptually) to pick out the ring if it lies entirely in the brackets. I'd go for a colon over # or @. Another issue: do we allow [1..10;
Re: [sage-devel] Re: Literal matrix syntax
Another issue: do we allow [1..10; 10..20]? We probably shouldn't go to extra effort to support it. I can't seem to construct matrices with matrix entries (this is not absurd) -- but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()] I'm not quite clear how these are square matrices (or even how the rows have the same length). What does [1..10; 10..20] translate to? David -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 5:15 PM, David Roe r...@math.harvard.edu wrote: Another issue: do we allow [1..10; 10..20]? We probably shouldn't go to extra effort to support it. I can't seem to construct matrices with matrix entries (this is not absurd) -- but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()] I'm not quite clear how these are square matrices (or even how the rows have the same length). What does [1..10; 10..20] translate to? Oops, I meant nesting like [ [1, 10; 10, 20].det() ; [2,12; 14, 24].det() ] should be supported, not the using the elipsis notation. -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 5:15 PM, David Roe r...@math.harvard.edu wrote: Another issue: do we allow [1..10; 10..20]? We probably shouldn't go to extra effort to support it. I can't seem to construct matrices with matrix entries (this is not absurd) -- but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()] I'm not quite clear how these are square matrices (or even how the rows have the same length). What does [1..10; 10..20] translate to? They aren't square... and worse, [1..10; 10..20] doesn't make sense since the top row has 9 entries whereas the bottom has 10. We're being sloppy for the sake of conversation. I tend to think that we should support ellipses, though I admit it's a corner case of limited utility. [0..2; 10..12] - [[0,1,2],[10,11,12]] David -- 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 -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 6:21 PM, Tom Boothby tomas.boot...@gmail.com wrote: On Thu, Jan 26, 2012 at 5:15 PM, David Roe r...@math.harvard.edu wrote: Another issue: do we allow [1..10; 10..20]? We probably shouldn't go to extra effort to support it. I can't seem to construct matrices with matrix entries (this is not absurd) -- but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()] I'm not quite clear how these are square matrices (or even how the rows have the same length). What does [1..10; 10..20] translate to? They aren't square... and worse, [1..10; 10..20] doesn't make sense since the top row has 9 entries whereas the bottom has 10. We're being sloppy for the sake of conversation. I tend to think that we should support ellipses, though I admit it's a corner case of limited utility. [0..2; 10..12] - [[0,1,2],[10,11,12]] As long as the two can be considered independently, I'm not against it (we could even handle list comprehensions). E.g. The transformation would be [X] - matrix([[ + ],[.join(X.split(;) + ]]) with the necessary precautions taken to appropriately handle splitting. -- 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: Literal matrix syntax
On 1/26/12 8:21 PM, Tom Boothby wrote:
On Thu, Jan 26, 2012 at 5:15 PM, David Roer...@math.harvard.edu wrote:
Another issue: do we allow [1..10; 10..20]?
We probably shouldn't go to extra effort to support it.
I can't seem to construct
matrices with matrix entries (this is not absurd) -- but should the
preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]]
Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()]
I'm not quite clear how these are square matrices (or even how the
rows have the same length). What does [1..10; 10..20] translate to?
They aren't square... and worse, [1..10; 10..20] doesn't make sense
since the top row has 9 entries whereas the bottom has 10. We're
being sloppy for the sake of conversation. I tend to think that we
should support ellipses, though I admit it's a corner case of limited
utility.
[0..2; 10..12] - [[0,1,2],[10,11,12]]
Two comments:
1. If [0..2, 10..12] works, I think matrix([[0..2],[10..12]]) should
work. Notice, with the current patch:
sage: matrix([[0..2],[10..12]])
[ 0 1 2]
[10 11 12]
sage: [0..2;10..12]
File ipython console, line 1
(ellipsis_range(Integer(0),Ellipsis,Integer(2);Integer(10),Ellipsis,Integer(12)))
^
SyntaxError: invalid syntax
sage: preparse('[0..1;3..4]')
'(ellipsis_range(Integer(0),Ellipsis,Integer(1);Integer(3),Ellipsis,Integer(4)))'
So maybe we just need to switch the order of preparsing? Indeed, moving
the matrix preparsing call ahead of the ellipsis call gives:
sage: preparse('[0..2; 3..5]')
'matrix([(ellipsis_range(Integer(0),Ellipsis,Integer(2))),(ellipsis_range(
Integer(3),Ellipsis,Integer(5)))])'
sage: [0..2; 3..5]
[0 1 2]
[3 4 5]
2. Matlab supports such notation (except they use a colon to give a
range, like 0:10 for [0..10] and 0:2:10 for [0..10,step=2]). It would
be nice if we supported it as well. With the above change, we also get
that for free:
sage: [0..10,step=2; 1..11,step=2]
[ 0 2 4 6 8 10]
[ 1 3 5 7 9 11]
sage: [0,2,..,10; 2,4,..,12]
[ 0 2 4 6 8 10]
[ 2 4 6 8 10 12]
I'm not sure if there is a problem with moving the matrix parsing up
that early in the preparsing stage, though.
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: Literal matrix syntax
First, like Simon said: But I wouldn't be so mean to prevent other people from using it. But I have trouble getting too excited about this new syntax. What we have works well for me and for my students. Second, I agree strongly when William said: I'm more for *consistency* between the matrix command the matrix notation Third, Marshall said: This makes it easier to win over people used to Matlab. Jason did a nice job of implementing matrices over RDF/ CDF so that SciPy/NumPy routines are trivial to wrap. (Doctesting them is another story.) I did a lot of this last spring when I had the time, with a lot of help from Martin Raum and others. Continuing to build out a full suite of numerical routines for RDF/CDF matrices would go even further toward being a viable alternative to Matlab. Rob -- 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
