Literal matrix syntax 
Robert Bradshaw 
1/26/12 12:22 AM 
I would like to propose the addition of a matrix literal syntax, namely sage: [1, 2; 3, 4] [1 2] [3 4] sage: [1, 2; 3, 4] * [5, 6; 7, 8] [19 22] [43 50] 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] This is a followup from the discussion at https://groups.google.com/forum/#!msg/sagedevel/pnrpKUBMm8/LUMAfoXszUJ , but brought to the forefront due to a wanting to publish something with many small matrices as examples. Not all the details need be fleshed out, but the basic idea is that a semicolon in within brackets would create a matrix (row). Nested matrices, trailing semicolons, spanning lines, etc. would of course be supported correctly and is not that hard of a challenge. Of course adding to the preparser should not be done lightly, but I think this is simple, useful, and intuitive enough to justify the diversion from pure Python. At this point I'm just looking for an up/down vote on whether we could count on something like this to go in, though more detailed design decision would be interesting as well. Preliminary patch at http://trac.sagemath.org/sage_trac/ticket/12354 . A second question, what of the basering? Lots of times it's more convenient to use the fraction field, especially if there was an easier way to set it "back" to ZZ for those who care about the it. One could go a step further and create matrices over RDF if the entries are in RR (as linear algebra over RR is both slow and bad). One of the main complaints I've heard about Sage from non (pure) mathematicians is that they feel that the abstract notions of rings, etc. are shoved in their face, and having to specify QQ every time an matrix is constructed falls into this... Thoughts?  Robert

Re: [sagedevel] Literal matrix syntax 
Marco Streng 
1/26/12 12:39 AM 
Op 26012012 8:22, Robert Bradshaw schreef: > I would like to propose the addition of a matrix literal syntax, namely > > sage: [1, 2; 3, 4] > [1 2] > [3 4]
+1 even gp has this > A second question, what of the basering? Consistency with "[Mm]atrix([[1,2],[3,4]])" would be most clear. So would you argue to change basering of that too?

Re: [sagedevel] Literal matrix syntax 
David Roe 
1/26/12 1:15 AM 
>> I would like to propose the addition of a matrix literal syntax, namely >> >> sage: [1, 2; 3, 4] >> [1 2] >> [3 4] > +1 +1 from me as well > >> A second question, what of the basering? > > Consistency with "[Mm]atrix([[1,2],[3,4]])" would be most clear. So would > you argue to change basering of that too?
Perhaps there could be a way to set a global base ring default: if all of the entries of matrix with without specified base ring coerce into the default base ring then the default ring is used, otherwise the universe of the entries is used. We could create init.sage files for common classes of users which would set such global preferences. So an engineering one would set the default to RDF; a linear algebra teaching one would set it to CC.... David

Re: Literal matrix syntax 
Dima Pasechnik 
1/26/12 1:32 AM 
No, that's not good. Cause this syntax forbids 1row matrices to be entered in this format (as it won't be possible to distinguish it from a list!)
Dima 
Re: [sagedevel] Re: Literal matrix syntax 
Marco Streng 
1/26/12 1:37 AM 

Re: [sagedevel] Re: Literal matrix syntax 
Dima Pasechnik 
1/26/12 1:43 AM 
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 1row 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 1tuple in Python.
then, for consistency, it should be then [1,2;3,4;], i.e. end each row with ; 
Re: [sagedevel] Re: Literal matrix syntax 
Mike Hansen 
1/26/12 1:46 AM 
On Thu, Jan 26, 2012 at 1:43 AM, Dima Pasechnik <dim...@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

Re: [sagedevel] Re: Literal matrix syntax 
Keshav Kini 
1/26/12 1:49 AM 
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 ! 
Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 1:51 AM 
On Thu, Jan 26, 2012 at 1:37 AM, Marco Streng <marco....@gmail.com> wrote: > 2012/1/26 Dima Pasechnik <dim...@gmail.com>: >> No, that's not good. >> >> Cause this syntax forbids 1row 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 1tuple 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

Re: [sagedevel] Re: Literal matrix syntax 
David Roe 
1/26/12 2:06 AM 
> 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

Re: [sagedevel] Re: Literal matrix syntax 
daly 
1/26/12 2:16 AM 
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 
Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 2:24 AM 
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

Re: [sagedevel] Re: Literal matrix syntax 
Dima Pasechnik 
1/26/12 2:49 AM 
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 :)

Re: [sagedevel] Re: Literal matrix syntax 
daly 
1/26/12 2:51 AM 
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 
Re: [sagedevel] Re: Literal matrix syntax 
David Roe 
1/26/12 3:05 AM 
> 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

Re: Literal matrix syntax 
Simon King 
1/26/12 3:07 AM 
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 1row 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 1tuple 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 
Re: [sagedevel] Re: Literal matrix syntax 
daly 
1/26/12 3:16 AM 
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 
Re: [sagedevel] Re: Literal matrix syntax 
Marco Streng 
1/26/12 3:30 AM 
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.

Re: Literal matrix syntax 
jason 
1/26/12 4:51 AM 
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 messageour 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 
Re: [sagedevel] Re: Literal matrix syntax 
Marco Streng 
1/26/12 5:54 AM 
2012/1/26 Jason Grout < jason...@creativetrax.com>: > That's part of the problem pointed out in an earlier messageour 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 53bit 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.

Re: Literal matrix syntax 
jason 
1/26/12 6:12 AM 
No, this is a linear algebra problem, not a general problem in Sage. Usually RR is better mathematically than RDF. Thanks, Jason 
Re: [sagedevel] Re: Literal matrix syntax 
William 
1/26/12 7:19 AM 
For example, with RDF the largest allowed number is actually pretty tiny: sage: a = 10.0^1000; a 1.00000000000000e1000 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...@googlegroups.com > To unsubscribe from this group, send an email to > sagedevel+...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org
 William Stein Professor of Mathematics University of Washington http://wstein.org

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 10:10 AM 
On Thu, Jan 26, 2012 at 2:51 AM, daly < da...@axiomdeveloper.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 subexpressions, at which point you might as well use matrix(R, ...).  Robert

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 10:13 AM 
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 linearalgebra 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...@creativetrax.com> wrote:
>  > To post to this group, send an email to sage...@googlegroups.com > To unsubscribe from this group, send an email to > sagedevel+...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org

Re: Literal matrix syntax 
Simon King 
1/26/12 11:34 AM 
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 linearalgebra 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 
Re: [sagedevel] Re: Literal matrix syntax 
Marco Streng 
1/26/12 11:38 AM 
> 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 linearalgebra 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?

Re: [sagedevel] Re: Literal matrix syntax 
Tom 
1/26/12 11:57 AM 
On Thu, Jan 26, 2012 at 10:13 AM, Robert Bradshaw < robe...@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 linearalgebra 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...@creativetrax.com> wrote: >> On 1/26/12 7:54 AM, Marco Streng wrote: >>> >>> 2012/1/26 Jason Grout<jason...@creativetrax.com>: >>>> >>>> That's part of the problem pointed out in an earlier messageour 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 53bit 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...@googlegroups.com >> To unsubscribe from this group, send an email to >> sagedevel+...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sagedevel >> URL: http://www.sagemath.org > >  > To post to this group, send an email to sage...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org

Re: [sagedevel] Re: Literal matrix syntax 
William 
1/26/12 12:04 PM 
On Thu, Jan 26, 2012 at 10:13 AM, Robert Bradshaw <robe...@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 linearalgebra 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?  William Stein Professor of Mathematics University of Washington http://wstein.org

Re: Literal matrix syntax 
jason 
1/26/12 12:09 PM 
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 
Re: Literal matrix syntax 
mhampton 
1/26/12 12:12 PM 
> 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 linearalgebra 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

Re: Literal matrix syntax 
jason 
1/26/12 12:10 PM 
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

Re: Literal matrix syntax 
jason 
1/26/12 12:19 PM 
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 linearalgebra 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 
Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 12:28 PM 
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout <jason...@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

Re: [sagedevel] Re: Literal matrix syntax 
Tom 
1/26/12 12:30 PM 
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout <jason...@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.

Re: [sagedevel] Re: Literal matrix syntax 
William 
1/26/12 12:35 PM 

Re: [sagedevel] Re: Literal matrix syntax 
Fernando Perez 
1/26/12 12:47 PM 
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout <jason...@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

Re: Literal matrix syntax 
kcrisman 
1/26/12 1:33 PM 
On Jan 26, 3:19 pm, Jason Grout <jasons...@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 linearalgebra 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. 
Re: [sagedevel] Re: Literal matrix syntax 
William 
1/26/12 1:36 PM 
On Thu, Jan 26, 2012 at 1:33 PM, kcrisman <kcri...@gmail.com> wrote: > > > On Jan 26, 3:19 pm, Jason Grout <jasons...@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 linearalgebra 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...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org William Stein Professor of Mathematics University of Washington http://wstein.org

Re: [sagedevel] Re: Literal matrix syntax 
Michael Orlitzky 
1/26/12 1:51 PM 
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.

Re: [sagedevel] Re: Literal matrix syntax 
William 
1/26/12 2:00 PM 
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky <mic...@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...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org William Stein Professor of Mathematics University of Washington http://wstein.org

Re: [sagedevel] Re: Literal matrix syntax 
Michael Orlitzky 
1/26/12 2:12 PM 
On 01/26/12 17:00, William Stein wrote: > On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky <mic...@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.

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 2:36 PM 
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky <mic...@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 multiline handling in the face of iPython (where each line needs to be preparsed 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 Sageonly feature. On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby <tomas....@gmail.com> wrote: > On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout > <jason...@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

Re: [sagedevel] Re: Literal matrix syntax 
Tom 
1/26/12 3:08 PM 
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...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 3:21 PM 
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

Re: [sagedevel] Re: Literal matrix syntax 
Tom 
1/26/12 3:51 PM 
On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw 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 absurd)  but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] > >  Robert > >  > To post to this group, send an email to sage...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 4:01 PM 
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()]  Robert

Re: [sagedevel] Re: Literal matrix syntax 
David Roe 
1/26/12 5:15 PM 
>> 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

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 5:40 PM 
Oops, I meant nesting like [ [1, 10; 10, 20].det() ; [2,12; 14, 24].det() ] should be supported, not the using the elipsis notation.

Re: [sagedevel] Re: Literal matrix syntax 
Tom 
1/26/12 6:21 PM 
On Thu, Jan 26, 2012 at 5:15 PM, David Roe <ro...@math.harvard.edu> wrote:
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...@googlegroups.com > To unsubscribe from this group, send an email to sagedevel+...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sagedevel > URL: http://www.sagemath.org

Re: [sagedevel] Re: Literal matrix syntax 
Robert Bradshaw 
1/26/12 7:19 PM 
On Thu, Jan 26, 2012 at 6:21 PM, Tom Boothby <tomas....@gmail.com> wrote: > On Thu, Jan 26, 2012 at 5:15 PM, David Roe <ro...@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.

Re: Literal matrix syntax 
jason 
1/26/12 7:29 PM 
On 1/26/12 8:21 PM, Tom Boothby wrote: > On Thu, Jan 26, 2012 at 5:15 PM, David Roe<ro...@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 
Re: Literal matrix syntax 
Rob Beezer 
1/26/12 9:23 PM 
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

Re: Literal matrix syntax 
Sébastien Labbé 
1/27/12 9:36 AM 
> 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 