> 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]]) * matr
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
On 1/26/12 8:21 PM, Tom Boothby wrote:
On Thu, Jan 26, 2012 at 5:15 PM, David Roe 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
preparse
On Thu, Jan 26, 2012 at 6:21 PM, Tom Boothby wrote:
> On Thu, Jan 26, 2012 at 5:15 PM, David Roe 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 no
On Thu, Jan 26, 2012 at 5:15 PM, David Roe 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; 1
On Thu, Jan 26, 2012 at 5:15 PM, David Roe 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; 1
>> 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;
On Thu, Jan 26, 2012 at 3:51 PM, Tom Boothby wrote:
> On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw
> wrote:
>> On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby wrote:
>>> On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw
>>> wrote:
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky
wr
On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw
wrote:
> On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby wrote:
>> On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw
>> wrote:
>>> On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky
>>> wrote:
On 01/26/12 16:36, William Stein wrote:
>>
>
On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby wrote:
> On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw
> wrote:
>> On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky
>> wrote:
>>> On 01/26/12 16:36, William Stein wrote:
>
> Why *not* use it?
The standard argument against prepar
On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw
wrote:
> On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky
> 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 us
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky 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
On 01/26/12 17:00, William Stein wrote:
> On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky
> 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
On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky 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
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
On Thu, Jan 26, 2012 at 1:33 PM, kcrisman wrote:
>
>
> On Jan 26, 3:19 pm, Jason Grout 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
>> >
On Jan 26, 3:19 pm, Jason Grout 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 Matl
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout
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://pydatawo
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout
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 S
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout
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
On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout
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;
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.
On 1/26/12 2:04 PM, William Stein wrote:
[X] No, matrices over QQ are for sissies, real mathematicians work
over ZZ unless otherwise specified.
That would go great in our linear algebra article or in the Sage docs ;)
Jason
--
To post to this group, send an email to sage-devel@googlegroups.co
> 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
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 lo
On Thu, Jan 26, 2012 at 10:13 AM, 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 miss
On Thu, Jan 26, 2012 at 10:13 AM, 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 miss
> 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 n
Hi Robert,
On 26 Jan., 19:13, Robert Bradshaw
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 horribl
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 ma
On Thu, Jan 26, 2012 at 2:51 AM, daly 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 p
On Thu, Jan 26, 2012 at 6:12 AM, Jason Grout
wrote:
> On 1/26/12 7:54 AM, Marco Streng wrote:
>>
>> 2012/1/26 Jason Grout:
>>>
>>> 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 (
On 1/26/12 7:54 AM, Marco Streng wrote:
2012/1/26 Jason Grout:
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, wher
2012/1/26 Jason Grout :
> 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 algorith
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 wou
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: "Ma
On Thu, 2012-01-26 at 03:05 -0800, David Roe wrote:
> > So I am suggesting that a clean syntax is possible if
> > the base ring is associated with the target symbol, not
> > with the input tokens.
>
> Apprently in Axiom you can statically type variable names, whereas in
> Python a variable is dyna
Hi all!
On 26 Jan., 10:37, Marco Streng wrote:
> 2012/1/26 Dima Pasechnik :
>
> > 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 prob
> 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 f
On Thu, 2012-01-26 at 02:24 -0800, Robert Bradshaw wrote:
> On Thu, Jan 26, 2012 at 2:16 AM, daly wrote:
> > On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote:
> >> > As for global defaults, it's nice for both examples and debugging for
> >> > there to be as little global state as possible, and s
Matlab users are spoiled, as everything is a matrix of floats there.
Do you know that 0==0.0 and 0==[0] in Matlab?
Going this way, we will end up renaming binomial() to nchoosek(), and
creating a Matlab clone :-)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubsc
On Thu, Jan 26, 2012 at 2:16 AM, daly wrote:
> On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote:
>> > As for global defaults, it's nice for both examples and debugging for
>> > there to be as little global state as possible, and someone who wants
>> > RDF for reals probably wants CDF for complex
On Thu, 2012-01-26 at 02:06 -0800, David Roe wrote:
> > As for global defaults, it's nice for both examples and debugging for
> > there to be as little global state as possible, and someone who wants
> > RDF for reals probably wants CDF for complexes. The consistency
> > argument is a good one, but
> 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 bot
On Thu, Jan 26, 2012 at 1:37 AM, Marco Streng wrote:
> 2012/1/26 Dima Pasechnik :
>> 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 pro
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
On Thu, Jan 26, 2012 at 1:43 AM, Dima Pasechnik wrote:
> then, for consistency, it should be then
> [1,2;3,4;], i.e. end each row with ;
It can be optional:
In [6]: (1,2,3)
Out[6]: (1, 2, 3)
In [7]: (1,2,3,)
Out[7]: (1, 2, 3)
--Mike
--
To post to this group, send an email to sage-devel@google
On Thursday, January 26, 2012 5:37:14 PM UTC+8, Marco Streng wrote:
>
> 2012/1/26 Dima Pasechnik :
> > 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(
2012/1/26 Dima Pasechnik :
> 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.
>
No, that's not good.
Cause this syntax forbids 1-row matrices to be entered in this format
(as it won't be possible to distinguish it from a list!)
Dima
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr..
50 matches
Mail list logo