Literal matrix syntax

293 views
Skip to first unread message

Robert Bradshaw

unread,
Jan 26, 2012, 3:22:27 AM1/26/12
to sage-devel
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/sage-devel/p-nrpKUBMm8/LUMAfoXsz-UJ
, 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 semi-colon 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

Marco Streng

unread,
Jan 26, 2012, 3:39:50 AM1/26/12
to sage-...@googlegroups.com
Op 26-01-2012 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?

David Roe

unread,
Jan 26, 2012, 4:15:30 AM1/26/12
to sage-...@googlegroups.com
>> 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

Dima Pasechnik

unread,
Jan 26, 2012, 4:32:52 AM1/26/12
to sage-...@googlegroups.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!)

Dima

Marco Streng

unread,
Jan 26, 2012, 4:37:14 AM1/26/12
to sage-...@googlegroups.com
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.

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

Dima Pasechnik

unread,
Jan 26, 2012, 4:43:28 AM1/26/12
to sage-...@googlegroups.com


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 ;

Mike Hansen

unread,
Jan 26, 2012, 4:46:44 AM1/26/12
to sage-...@googlegroups.com
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

Keshav Kini

unread,
Jan 26, 2012, 4:49:38 AM1/26/12
to sage-...@googlegroups.com
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 !

Robert Bradshaw

unread,
Jan 26, 2012, 4:51:31 AM1/26/12
to sage-...@googlegroups.com
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 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

David Roe

unread,
Jan 26, 2012, 5:06:13 AM1/26/12
to sage-...@googlegroups.com
> 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

daly

unread,
Jan 26, 2012, 5:16:50 AM1/26/12
to sage-...@googlegroups.com

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

Robert Bradshaw

unread,
Jan 26, 2012, 5:24:49 AM1/26/12
to sage-...@googlegroups.com

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

Dima Pasechnik

unread,
Jan 26, 2012, 5:49:58 AM1/26/12
to sage-...@googlegroups.com
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 :-) 

daly

unread,
Jan 26, 2012, 5:51:14 AM1/26/12
to sage-...@googlegroups.com

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

David Roe

unread,
Jan 26, 2012, 6:05:40 AM1/26/12
to sage-...@googlegroups.com
> 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

Simon King

unread,
Jan 26, 2012, 6:07:14 AM1/26/12
to sage-devel
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

daly

unread,
Jan 26, 2012, 6:16:17 AM1/26/12
to sage-...@googlegroups.com
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

Marco Streng

unread,
Jan 26, 2012, 6:30:26 AM1/26/12
to sage-...@googlegroups.com
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.

Jason Grout

unread,
Jan 26, 2012, 7:51:05 AM1/26/12
to sage-...@googlegroups.com
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

Marco Streng

unread,
Jan 26, 2012, 8:54:54 AM1/26/12
to sage-...@googlegroups.com
2012/1/26 Jason Grout <jason...@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.

Jason Grout

unread,
Jan 26, 2012, 9:12:55 AM1/26/12
to sage-...@googlegroups.com

No, this is a linear algebra problem, not a general problem in Sage.
Usually RR is better mathematically than RDF.

Thanks,

Jason

William Stein

unread,
Jan 26, 2012, 10:19:18 AM1/26/12
to sage-...@googlegroups.com

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
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Robert Bradshaw

unread,
Jan 26, 2012, 1:10:09 PM1/26/12
to sage-...@googlegroups.com
On Thu, Jan 26, 2012 at 2:51 AM, daly <da...@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

Robert Bradshaw

unread,
Jan 26, 2012, 1:13:58 PM1/26/12
to sage-...@googlegroups.com
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...@creativetrax.com> wrote:

Simon King

unread,
Jan 26, 2012, 2:34:35 PM1/26/12
to sage-devel
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

Marco Streng

unread,
Jan 26, 2012, 2:38:25 PM1/26/12
to sage-...@googlegroups.com
> 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?

Tom Boothby

unread,
Jan 26, 2012, 2:57:31 PM1/26/12
to sage-...@googlegroups.com
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 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]

William Stein

unread,
Jan 26, 2012, 3:04:20 PM1/26/12
to sage-...@googlegroups.com
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 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

--

Jason Grout

unread,
Jan 26, 2012, 3:09:56 PM1/26/12
to sage-...@googlegroups.com
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

mhampton

unread,
Jan 26, 2012, 3:12:47 PM1/26/12
to sage-devel

> 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

Jason Grout

unread,
Jan 26, 2012, 3:10:55 PM1/26/12
to sage-...@googlegroups.com
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


Jason Grout

unread,
Jan 26, 2012, 3:19:39 PM1/26/12
to sage-...@googlegroups.com
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

Robert Bradshaw

unread,
Jan 26, 2012, 3:28:45 PM1/26/12
to sage-...@googlegroups.com
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

Tom Boothby

unread,
Jan 26, 2012, 3:30:41 PM1/26/12
to sage-...@googlegroups.com
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.

William Stein

unread,
Jan 26, 2012, 3:35:28 PM1/26/12
to sage-...@googlegroups.com

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

--

Fernando Perez

unread,
Jan 26, 2012, 3:47:37 PM1/26/12
to sage-...@googlegroups.com
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

kcrisman

unread,
Jan 26, 2012, 4:33:14 PM1/26/12
to sage-devel


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.

William Stein

unread,
Jan 26, 2012, 4:36:31 PM1/26/12
to sage-...@googlegroups.com
On Thu, Jan 26, 2012 at 1:33 PM, kcrisman <kcri...@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-...@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

--

Michael Orlitzky

unread,
Jan 26, 2012, 4:51:28 PM1/26/12
to sage-...@googlegroups.com
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.

William Stein

unread,
Jan 26, 2012, 5:00:28 PM1/26/12
to sage-...@googlegroups.com
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.
>

Michael Orlitzky

unread,
Jan 26, 2012, 5:12:17 PM1/26/12
to sage-...@googlegroups.com
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.

Robert Bradshaw

unread,
Jan 26, 2012, 5:36:09 PM1/26/12
to sage-...@googlegroups.com
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
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....@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

Tom Boothby

unread,
Jan 26, 2012, 6:08:30 PM1/26/12
to sage-...@googlegroups.com

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

Robert Bradshaw

unread,
Jan 26, 2012, 6:21:16 PM1/26/12
to sage-...@googlegroups.com

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

Tom Boothby

unread,
Jan 26, 2012, 6:51:50 PM1/26/12
to sage-...@googlegroups.com
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 Bradshaw

unread,
Jan 26, 2012, 7:01:52 PM1/26/12
to sage-...@googlegroups.com

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

David Roe

unread,
Jan 26, 2012, 8:15:33 PM1/26/12
to sage-...@googlegroups.com
>> 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

Robert Bradshaw

unread,
Jan 26, 2012, 8:40:56 PM1/26/12
to sage-...@googlegroups.com

Oops, I meant nesting like [ [1, 10; 10, 20].det() ; [2,12; 14,
24].det() ] should be supported, not the using the elipsis notation.

Tom Boothby

unread,
Jan 26, 2012, 9:21:57 PM1/26/12
to sage-...@googlegroups.com
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

Robert Bradshaw

unread,
Jan 26, 2012, 10:19:01 PM1/26/12
to sage-...@googlegroups.com
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.

Jason Grout

unread,
Jan 26, 2012, 10:29:19 PM1/26/12
to sage-...@googlegroups.com
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

Rob Beezer

unread,
Jan 27, 2012, 12:23:30 AM1/27/12
to sage-devel
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

Sébastien Labbé

unread,
Jan 27, 2012, 12:36:40 PM1/27/12
to sage-devel
> 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
Reply all
Reply to author
Forward
0 new messages