Shorthand array creation in `numpy.mat` style
The idea is that there be a shorthand for creating arrays as there is for matrices:
np.mat('.2 .7 .1; .3 .5 .2; .1 .1 .9')
It was suggested in GitHub issue #4817 https://github.com/numpy/numpy/issues/4817 in light that it would be beneficial to beginners and to presenters during demonstrations. In GitHub pull request #484 https://github.com/numpy/numpy/pull/4845, I implemented this as the np.arr function.
Does anyone have any feedback on the API details? Some examples from my implementation follow.
np.arr('3; 4; 5')
array([[3], [4], [5]])
np.arr('3; 4; 5', dtype=float)
array([[ 3.], [ 4.], [ 5.]])
np.arr('1 0 0; 0 1 0; 0 0 1')
array([[1, 0, 0], [0, 1, 0], [0, 0, 1]])
np.arr('4, 5; 6, 7')
array([[4, 5], [6, 7]])
On Sun, Jul 6, 2014 at 9:35 PM, Daniel da Silva var.mail.daniel@gmail.com wrote:
The idea is that there be a shorthand for creating arrays as there is for matrices:
np.mat('.2 .7 .1; .3 .5 .2; .1 .1 .9')
It was suggested in GitHub issue #4817 in light that it would be beneficial to beginners and to presenters during demonstrations. In GitHub pull request #484, I implemented this as the np.arr function.
Does anyone have any feedback on the API details? Some examples from my implementation follow.
np.arr('3; 4; 5')
array([[3], [4], [5]])
np.arr('3; 4; 5', dtype=float)
array([[ 3.], [ 4.], [ 5.]])
np.arr('1 0 0; 0 1 0; 0 0 1')
array([[1, 0, 0], [0, 1, 0], [0, 0, 1]])
np.arr('4, 5; 6, 7')
array([[4, 5], [6, 7]])
It occurs to me that np.mat always returns a 2d matrix, but for arrays there are more options.
What should np.arr('1 2 3') return? a 1d array or a 2d row vector? (Maybe np.arr('1 2 3;') should give the rowvector?)
Should there be some way to write 3d or higherd arrays?
n
On 2014/07/06, 11:43 AM, Nathaniel Smith wrote:
On Sun, Jul 6, 2014 at 9:35 PM, Daniel da Silva var.mail.daniel@gmail.com wrote:
The idea is that there be a shorthand for creating arrays as there is for matrices:
np.mat('.2 .7 .1; .3 .5 .2; .1 .1 .9')
It was suggested in GitHub issue #4817 in light that it would be beneficial to beginners and to presenters during demonstrations. In GitHub pull request #484, I implemented this as the np.arr function.
Does anyone have any feedback on the API details? Some examples from my implementation follow.
np.arr('3; 4; 5')
array([[3], [4], [5]])
np.arr('3; 4; 5', dtype=float)
array([[ 3.], [ 4.], [ 5.]])
np.arr('1 0 0; 0 1 0; 0 0 1')
array([[1, 0, 0], [0, 1, 0], [0, 0, 1]])
np.arr('4, 5; 6, 7')
array([[4, 5], [6, 7]])
It occurs to me that np.mat always returns a 2d matrix, but for arrays there are more options.
What should np.arr('1 2 3') return? a 1d array or a 2d row vector?
I would say 1d array. This is numpy, not numpy.matrix.
(Maybe np.arr('1 2 3;') should give the rowvector?)
Yes, it is reasonable that a semicolon should trigger 2d.
Should there be some way to write 3d or higherd arrays?
No, there should not. This is for quick demos and that sort of thing. It is not a substitute for np.array(). (I'm not entirely convinced np.arr() is a good idea at all; but if it is, it must be kept simple.)
A possible downside for beginners is that this might delay their understanding that the commas are needed for np.array([1, 2, 3]).
Eric
n
On Sun, Jul 6, 2014 at 6:06 PM, Eric Firing efiring@hawaii.edu wrote:
(I'm not entirely convinced np.arr() is a good idea at all; but if it is, it must be kept simple.)
If you are going to introduce this functionality, please don't call it np.arr.
Right now, np.a<tab> presents you with a whopping 53 completion choices. Adding "r", narrows that to 21, but np.arr<tab> completes to np.array right away. Please don't introduce another bump in this road.
"Namespaces are one honking great idea  let's do more of those!"
I would suggest calling it something like np.array_simple or np.array_from_string, but the best choice IMO, would be np.ndarray.from_string (a static constructor method).
On 2014/07/06, 4:27 PM, Alexander Belopolsky wrote:
On Sun, Jul 6, 2014 at 6:06 PM, Eric Firing <efiring@hawaii.edu mailto:efiring@hawaii.edu> wrote:
(I'm not entirely convinced np.arr() is a good idea at all; but if it is, it must be kept simple.)
If you are going to introduce this functionality, please don't call it np.arr.
Right now, np.a<tab> presents you with a whopping 53 completion choices. Adding "r", narrows that to 21, but np.arr<tab> completes to np.array right away. Please don't introduce another bump in this road.
"Namespaces are one honking great idea  let's do more of those!"
I would suggest calling it something like np.array_simple or np.array_from_string, but the best choice IMO, would be np.ndarray.from_string (a static constructor method).
I think the problem is that this defeats the point: minimizing typing when doing an offthecuff demo or test. I don't know that this use case justifies the clutter, regardless of what it is called; but evidently there is some demand for it.
Eric
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Sun, Jul 6, 2014 at 10:59 PM, Eric Firing efiring@hawaii.edu wrote:
I would suggest calling it something like np.array_simple or np.array_from_string, but the best choice IMO, would be np.ndarray.from_string (a static constructor method).
I think the problem is that this defeats the point: minimizing typing when doing an offthecuff demo or test.
You can always put np.arr = np.ndarray.from_string or even arr = np.ndarray.from_string right next to the line where you define np. (Which makes me wonder if something like this belongs to ipython magic.)
How about using the old name np.mat() for this type of array creation?
So the:
A = np.mat(“1 2;3 4”)
creates a two dimensional array.
But then resulting in an array A instead of the matrix type? It might at least provide some partial downward compatibility.
Best regards, Jacco Hoekstra
From: numpydiscussionbounces@scipy.org [mailto:numpydiscussionbounces@scipy.org] On Behalf Of Alexander Belopolsky Sent: maandag 7 juli 2014 6:30 To: Discussion of Numerical Python Subject: Re: [Numpydiscussion] Shorthand array creation in `numpy.mat` style
On Sun, Jul 6, 2014 at 10:59 PM, Eric Firing <efiring@hawaii.edumailto:efiring@hawaii.edu> wrote:
I would suggest calling it something like np.array_simple or np.array_from_string, but the best choice IMO, would be np.ndarray.from_string (a static constructor method).
I think the problem is that this defeats the point: minimizing typing when doing an offthecuff demo or test.
You can always put np.arr = np.ndarray.from_string or even arr = np.ndarray.from_string right next to the line where you define np. (Which makes me wonder if something like this belongs to ipython magic.)
On 7 July 2014 08:48, Jacco Hoekstra  LR J.M.Hoekstra@tudelft.nl wrote:
How about using the old name np.mat() for this type of array creation?
How about a new one? np.matarray, for MATLAB array.
/David.
On 7/7/2014 7:17 AM, Daπid wrote:
How about a new one? np.matarray, for MATLAB array.
How about `str2arr` or even `build`, since teaching appears to be a focus. Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. It seems unambiguous to allow '1 2 3;;' to be 3d, or even '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting that, not urging that it be implemented.
Alan Isaac
On Mo, 20140707 at 08:25 0400, Alan G Isaac wrote:
On 7/7/2014 7:17 AM, Daπid wrote:
How about a new one? np.matarray, for MATLAB array.
How about `str2arr` or even `build`, since teaching appears to be a focus. Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. It seems unambiguous to allow '1 2 3;;' to be 3d, or even '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting that, not urging that it be implemented.
Probably overdoing it, but if we plan on more then just this, what about banning such functions to something like numpy.interactive/numpy.helpers which you can then import * (or better specific functions) from?
I think the fact that you need many imports on startup should rather be fixed by an ipython scientific mode or other startup imports.
 Sebastian
Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Mo, 20140707 at 08:25 0400, Alan G Isaac wrote:
On 7/7/2014 7:17 AM, Daπid wrote:
How about a new one? np.matarray, for MATLAB array.
How about `str2arr` or even `build`, since teaching appears to be a
focus.
Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. It seems unambiguous to allow '1 2 3;;' to be 3d, or even '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting that, not urging that it be implemented.
Probably overdoing it, but if we plan on more then just this, what about banning such functions to something like numpy.interactive/numpy.helpers which you can then import * (or better specific functions) from?
I think the fact that you need many imports on startup should rather be fixed by an ipython scientific mode or other startup imports.
Is this whole thing really worth it? We get back to a numpy pylab.
First users learn the dirty shortcuts, and then they have to learn how to do it "properly".
(I'm using quite often string split and reshape for copypasted text tables.)
Josef
 Sebastian
Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mo, 20140707 at 09:50 0400, josef.pktd@gmail.com wrote:
On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Mo, 20140707 at 08:25 0400, Alan G Isaac wrote: > On 7/7/2014 7:17 AM, Daπid wrote: > > How about a new one? np.matarray, for MATLAB array. > > > How about `str2arr` or even `build`, since teaching appears to be a focus. > Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. > It seems unambiguous to allow '1 2 3;;' to be 3d, or even > '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting > that, not urging that it be implemented. >
Probably overdoing it, but if we plan on more then just this, what about banning such functions to something like numpy.interactive/numpy.helpers which you can then import * (or better specific functions) from? I think the fact that you need many imports on startup should rather be fixed by an ipython scientific mode or other startup imports.
Is this whole thing really worth it? We get back to a numpy pylab.
First users learn the dirty shortcuts, and then they have to learn how to do it "properly".
Yeah, you are right. Just a bit afraid of creating too many such functions that I am not sure are very useful/used much. For example I am not sure that many use np.r_ or np.c_
(I'm using quite often string split and reshape for copypasted text tables.)
Josef
 Sebastian > Alan Isaac > > _______________________________________________ > NumPyDiscussion mailing list > NumPyDiscussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpydiscussion _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Mo, 20140707 at 09:50 0400, josef.pktd@gmail.com wrote:
On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Mo, 20140707 at 08:25 0400, Alan G Isaac wrote: > On 7/7/2014 7:17 AM, Daπid wrote: > > How about a new one? np.matarray, for MATLAB array. > > > How about `str2arr` or even `build`, since teaching appears to be a focus. > Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. > It seems unambiguous to allow '1 2 3;;' to be 3d, or even > '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting > that, not urging that it be implemented. >
Probably overdoing it, but if we plan on more then just this, what about banning such functions to something like numpy.interactive/numpy.helpers which you can then import * (or better specific functions) from? I think the fact that you need many imports on startup should rather be fixed by an ipython scientific mode or other startup imports.
Is this whole thing really worth it? We get back to a numpy pylab.
First users learn the dirty shortcuts, and then they have to learn how to do it "properly".
Yeah, you are right. Just a bit afraid of creating too many such functions that I am not sure are very useful/used much. For example I am not sure that many use np.r_ or np.c_
Yeah, we definitely have too many random bits of API around overall. But I think this one is probably worthwhile. It doesn't add any real complexity (no new types, trivial for readers to understand the first time they encounter it, etc.), and it addresses a recurring perceived shortcoming of numpy that people run into in the first 5 minutes of use, at a time when it's pretty easy to give up and go back to Matlab. And, it removes one of the perceived advantages of np.matrix over np.ndarray, so it smooths our way for eventually phasing out np.matrix.
I'm not sure that preserving np.arr<tab> is that important (<tab> here only saves 1 character!), but some possible alternatives for short names:
np.marr ("matlablike array construction") np.sarr ("string array") np.parse
n
On Mon, Jul 7, 2014 at 1:58 PM, Nathaniel Smith njs@pobox.com wrote:
On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Mo, 20140707 at 09:50 0400, josef.pktd@gmail.com wrote:
On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Mo, 20140707 at 08:25 0400, Alan G Isaac wrote: > On 7/7/2014 7:17 AM, Daπid wrote: > > How about a new one? np.matarray, for MATLAB array. > > > How about `str2arr` or even `build`, since teaching appears to be a focus. > Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. > It seems unambiguous to allow '1 2 3;;' to be 3d, or even > '1 2;3 4;;5 6;7 8' (two 2d arrays), but I'm just noting > that, not urging that it be implemented. >
Probably overdoing it, but if we plan on more then just this, what about banning such functions to something like numpy.interactive/numpy.helpers which you can then import * (or better specific functions) from? I think the fact that you need many imports on startup should rather be fixed by an ipython scientific mode or other startup imports.
Is this whole thing really worth it? We get back to a numpy pylab.
First users learn the dirty shortcuts, and then they have to learn how to do it "properly".
Yeah, you are right. Just a bit afraid of creating too many such functions that I am not sure are very useful/used much. For example I am not sure that many use np.r_ or np.c_
Yeah, we definitely have too many random bits of API around overall. But I think this one is probably worthwhile. It doesn't add any real complexity (no new types, trivial for readers to understand the first time they encounter it, etc.), and it addresses a recurring perceived shortcoming of numpy that people run into in the first 5 minutes of use, at a time when it's pretty easy to give up and go back to Matlab. And, it removes one of the perceived advantages of np.matrix over np.ndarray, so it smooths our way for eventually phasing out np.matrix.
I'm not sure that preserving np.arr<tab> is that important (<tab> here only saves 1 character!), but some possible alternatives for short names:
np.marr ("matlablike array construction") np.sarr ("string array") np.parse
short like np.s (didn't know there is already s_)
something long like
np.fromstring('1 2', sep=' ')
array([ 1., 2.])
np.fromstring2d('1 2 3; 5 3.4 7')
array([[ 1. , 2. , 3. ], [ 5. , 3.4, 7. ]])
Josef
n
 Nathaniel J. Smith Postdoctoral researcher  Informatics  University of Edinburgh http://vorpus.org _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Jul 7, 2014, at 7:28 AM, Sebastian Berg sebastian@sipsolutions.net wrote:
not sure that many use np.r_ or np.c_
I actually really like those ;)
Chris
If you are going to introduce this functionality, please don't call it np.arr.
I agree, but..,
I would suggest calling it something like np.array_simple or np.array_from_string, but the best choice IMO, would be np.ndarray.from_string (a static constructor method).
Except the entire point of his is that it's easy to type...
1 on the whole idea  this isn't Matlab, I'd saving a little typing worth it?
CHB
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
07.07.2014 21:32, Chris Barker  NOAA Federal kirjoitti:
If you are going to introduce this functionality, please don't call it np.arr.
It might be appropriate for pirate versions of Numpy.
***
Seriously though, having a variant of `mat` that returns arrays could be useful, so weak +0. Preferably, the name should be quite short to type.
On the other hand, unlike r_ and c_, I haven't seen or used mat() in real code.
I think the idea at hand is not that it would be used everyday, but it would be there when needed. What people do everyday is with *real* data. They are using functions to load the data. Where this would come in useful would be presentations and tutorials.
If leading a presentation on scientific computing in Python to beginners, which would look better on a bullet in a slide?

np.build('.2 .7 .1; .3 .5 .2; .1 .1 .9'))

np.array([[.2, .7, .1], [.3, .5, .2], [.1, .1, .9]])
The default way of defining contrived arrays by passing lists of lists is awkward for beginners. While lists of lists are not a hard concept, it's not something you want to force on someone who doesn't know the Python language yet. The second bullet above doesn't represent the readability of the Python world.
I would suggest that this be named np.build() (or np.helpers.build()) in light of it providing a simple interface to building arrays. Again, when you work with real data you are taking an extra step to think about how you load that data. That's not what you need to think about when being introduced to NumPy.
On Tue, Jul 8, 2014 at 9:09 AM, Pauli Virtanen pav@iki.fi wrote:
07.07.2014 21:32, Chris Barker  NOAA Federal kirjoitti:
If you are going to introduce this functionality, please don't call it np.arr.
It might be appropriate for pirate versions of Numpy.
***
Seriously though, having a variant of `mat` that returns arrays could be useful, so weak +0. Preferably, the name should be quite short to type.
On the other hand, unlike r_ and c_, I haven't seen or used mat() in real code.
 Pauli Virtanen
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 11 July 2014 22:30, Daniel da Silva var.mail.daniel@gmail.com wrote:
I think the idea at hand is not that it would be used everyday, but it would be there when needed. What people do everyday is with *real* data. They are using functions to load the data.
But sometimes we have to hardcode a few values, and it is true that making a list (or nested list) is quite verbose; one example are unittests. Having a MATLABstyle array creation would be convenient for those cases.
On Fri, Jul 11, 2014 at 4:30 PM, Daniel da Silva var.mail.daniel@gmail.com wrote:
If leading a presentation on scientific computing in Python to beginners, which would look better on a bullet in a slide?
np.build('.2 .7 .1; .3 .5 .2; .1 .1 .9'))
np.array([[.2, .7, .1], [.3, .5, .2], [.1, .1, .9]])
np.array([[.2, .7, .1],
[.3, .5, .2], [.1, .1, .9]])
Also, the use of strings will confuse most syntax highlighters. Compare the two options in this screenshot:
[image: Inline image 2]
WeIl, I do not see the confusion here (only due to the use of the array function, maybe). It is a string, after all, so it should be colourcoded as such.
I would love to keep this feaure of np.mat in somehow, named np.txt2arr or something. We, linear algebraists, will already lose the .I method for matrix inversion, the * for matrix multiplication, let’s keep at least one of the many handy features of the matrixtype in. It is simply a very useful, shorthand way, probably a separate function, to make a 2Darray. If you think it’s ugly, don’t use it. But it certainly is faster to type it and former Matlabusers will love it as well. Just my 2 cts.
From: numpydiscussionbounces@scipy.org [mailto:numpydiscussionbounces@scipy.org] On Behalf Of Alexander Belopolsky Sent: zondag 13 juli 2014 19:31 To: Discussion of Numerical Python Subject: Re: [Numpydiscussion] Shorthand array creation in `numpy.mat` style
Also, the use of strings will confuse most syntax highlighters. Compare the two options in this screenshot:
[Inline image 2]
On Sun, Jul 13, 2014 at 6:31 PM, Alexander Belopolsky ndarray@mac.com wrote:
Also, the use of strings will confuse most syntax highlighters. Compare the two options in this screenshot:
[image: Inline image 2]
I guess this is a minor issue for "real" code, but even IPython doesn't (yet?) provide syntax highlighting for lines as they're typed, and this is a tool intended mainly for interactive use.
That screenshot also I think illustrates why people have such a preference for the first syntax. The second line looks nice, but try typing it quickly and getting all the commas located correctly inside versus outside of each of the triplynested brackets...
Noone's come up with any names for this that are nearly as good as "arr". Is it really that bad to have to type one extra character, np.array instead of np.arr<tab>?
n
1 on the 'arr' name. I think if we're going to support this function at all (which I'm not convinced is a good idea), it should be np.fromsomething like the other from* functions.
Maybe frommatlab?
I think that 'arr' is just too generic and too close to 'array'.
On Tue, Jul 15, 2014 at 3:55 AM, Nathaniel Smith njs@pobox.com wrote:
On Sun, Jul 13, 2014 at 6:31 PM, Alexander Belopolsky ndarray@mac.com wrote:
Also, the use of strings will confuse most syntax highlighters. Compare the two options in this screenshot:
[image: Inline image 2]
I guess this is a minor issue for "real" code, but even IPython doesn't (yet?) provide syntax highlighting for lines as they're typed, and this is a tool intended mainly for interactive use.
That screenshot also I think illustrates why people have such a preference for the first syntax. The second line looks nice, but try typing it quickly and getting all the commas located correctly inside versus outside of each of the triplynested brackets...
Noone's come up with any names for this that are nearly as good as "arr". Is it really that bad to have to type one extra character, np.array instead of np.arr<tab>?
n
 Nathaniel J. Smith Postdoctoral researcher  Informatics  University of Edinburgh http://vorpus.org
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman charles@crunch.io wrote:
1 on the 'arr' name. I think if we're going to support this function at all (which I'm not convinced is a good idea), it should be np.fromsomething like the other from* functions.
Maybe frommatlab?
I think that 'arr' is just too generic and too close to 'array'.
Well, it's definitely not a good idea if we name it something like that :).
The whole motivation is to provide a quick way to type 2d arrays interactively, hence the current name "np.mat". (The fact that it happens to match matlab syntax is a nice bonus, because stealing is always better than inventing when it works.)
I greatly prefer "np.mat" to "np.arr" for this, FWIW
On Fri, Jul 18, 2014 at 3:37 AM, Nathaniel Smith njs@pobox.com wrote:
On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman charles@crunch.io wrote:
1 on the 'arr' name. I think if we're going to support this function at all (which I'm not convinced is a good idea), it should be np.fromsomething like the other from* functions.
Maybe frommatlab?
I think that 'arr' is just too generic and too close to 'array'.
Well, it's definitely not a good idea if we name it something like that :).
The whole motivation is to provide a quick way to type 2d arrays interactively, hence the current name "np.mat". (The fact that it happens to match matlab syntax is a nice bonus, because stealing is always better than inventing when it works.)
 Nathaniel J. Smith Postdoctoral researcher  Informatics  University of Edinburgh http://vorpus.org _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Jul 18, 2014 at 3:02 PM, Charles G. Waldman charles@crunch.io wrote:
I greatly prefer "np.mat" to "np.arr" for this, FWIW
Unfortunately that's already taken...
On Fri, Jul 18, 2014 at 3:37 AM, Nathaniel Smith njs@pobox.com wrote:
On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman charles@crunch.io wrote:
1 on the 'arr' name. I think if we're going to support this function
at all (which I'm not convinced is a good idea), it should be np.fromsomething like the other from* functions.
Maybe frommatlab?
I think that 'arr' is just too generic and too close to 'array'.
Well, it's definitely not a good idea if we name it something like that :).
The whole motivation is to provide a quick way to type 2d arrays interactively, hence the current name "np.mat". (The fact that it happens to match matlab syntax is a nice bonus, because stealing is always better than inventing when it works.)
Some minor confusion on my part. If the true goal is to just allow quick entry of a 2d array, why not just advocate using
a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
If anyone is really set on having this functionality, they could just write a oneline wrapper function and call it a day.
Note that I would personally not use this type of shorthand syntax for teaching or presentations. I'd prefer to use proper python syntax myself from the get go rather than having to start over from square one and teach a completely different syntax for constructing >2d arrays.
"There should be one and preferably only one obvious way to do it." Zen of Python Mark
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not just advocate using a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
fwiw, Alan Isaac
Well, if the goal is "shorthand", typing numpy.array(numpy.mat()) won't please many users.
But the more I think about it, the less I think Numpy should support this (nonPythonic) input mode. Too much mollycoddling of new users! When doing interactive work I usually just type:
np.array([[1,2,3],
... [4,5,6], ... [7,8,9]])
which is (IMO) easier to read: e.g. it's not totally obvious that "1,0,0;0,1,0;0,0,1" represents a 3x3 identity matrix, but
[[1,0,0], [0,1,0], [0,0,1]]
is pretty obvious.
The difference in (nonwhitespace) chars is 19 vs 25, so the "shorthand" doesn't seem to save that much.
Just my €0.02,
 C
On Fri, Jul 18, 2014 at 10:05 AM, Alan G Isaac alan.isaac@gmail.com wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not just advocate using a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
fwiw, Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
Le 18/07/2014 20:42, Charles G. Waldman a écrit :
Well, if the goal is "shorthand", typing numpy.array(numpy.mat()) won't please many users.
But the more I think about it, the less I think Numpy should support this (nonPythonic) input mode. Too much mollycoddling of new users! When doing interactive work I usually just type:
np.array([[1,2,3],
... [4,5,6], ... [7,8,9]])
which is (IMO) easier to read: e.g. it's not totally obvious that "1,0,0;0,1,0;0,0,1" represents a 3x3 identity matrix, but
[[1,0,0], [0,1,0], [0,0,1]]
is pretty obvious.
Compare what's comparable:
[[1,0,0], [0,1,0], [0,0,1]]
vs
"1 0 0;" "0 1 0;" "0 0 1"
or
""" 1 0 0; 0 1 0; 0 0 1 """
[[1,0,0], [0,1,0], [0,0,1]] vs "1 0 0; 0 1 0; 0 0 1"
The difference in (nonwhitespace) chars is 19 vs 25, so the "shorthand" doesn't seem to save that much.
Well, it's easier to type "" (twice the same character) than [], and you have no risk in swapping en opening and a closing bracket. In addition, you have to use AltGr on some keyboards to get the brackets. It doesn't boils down to a number of characters.
Just my €0.02,
 C
On Fri, Jul 18, 2014 at 10:05 AM, Alan G Isaac alan.isaac@gmail.com wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not just advocate using a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
fwiw, Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
Joseph MartinotLagarde writes:
Compare what's comparable:
That's fair.
In addition, you have to use AltGr on some keyboards to get the brackets
Wow, it must be rather painful to do any real programming on such a keyboard!
 C
On Fri, Jul 18, 2014 at 1:15 PM, Joseph MartinotLagarde joseph.martinotlagarde@m4x.org wrote:
Le 18/07/2014 20:42, Charles G. Waldman a écrit :
Well, if the goal is "shorthand", typing numpy.array(numpy.mat()) won't please many users.
But the more I think about it, the less I think Numpy should support this (nonPythonic) input mode. Too much mollycoddling of new users! When doing interactive work I usually just type:
np.array([[1,2,3],
... [4,5,6], ... [7,8,9]])
which is (IMO) easier to read: e.g. it's not totally obvious that "1,0,0;0,1,0;0,0,1" represents a 3x3 identity matrix, but
[[1,0,0], [0,1,0], [0,0,1]]
is pretty obvious.
Compare what's comparable:
[[1,0,0], [0,1,0], [0,0,1]]
vs
"1 0 0;" "0 1 0;" "0 0 1"
or
""" 1 0 0; 0 1 0; 0 0 1 """
[[1,0,0], [0,1,0], [0,0,1]] vs "1 0 0; 0 1 0; 0 0 1"
The difference in (nonwhitespace) chars is 19 vs 25, so the "shorthand" doesn't seem to save that much.
Well, it's easier to type "" (twice the same character) than [], and you have no risk in swapping en opening and a closing bracket. In addition, you have to use AltGr on some keyboards to get the brackets. It doesn't boils down to a number of characters.
Just my €0.02,
 C
On Fri, Jul 18, 2014 at 10:05 AM, Alan G Isaac alan.isaac@gmail.com wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not just advocate using a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
fwiw, Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Jul 18, 2014 at 4:21 PM, Charles G. Waldman charles@crunch.io wrote:
Joseph MartinotLagarde writes:
Compare what's comparable:
That's fair.
In addition, you have to use AltGr on some keyboards to get the brackets
Wow, it must be rather painful to do any real programming on such a keyboard!
 C
On Fri, Jul 18, 2014 at 1:15 PM, Joseph MartinotLagarde joseph.martinotlagarde@m4x.org wrote:
Le 18/07/2014 20:42, Charles G. Waldman a écrit :
Well, if the goal is "shorthand", typing numpy.array(numpy.mat()) won't please many users.
But the more I think about it, the less I think Numpy should support this (nonPythonic) input mode. Too much mollycoddling of new users! When doing interactive work I usually just type:
np.array([[1,2,3],
... [4,5,6], ... [7,8,9]])
which is (IMO) easier to read: e.g. it's not totally obvious that "1,0,0;0,1,0;0,0,1" represents a 3x3 identity matrix, but
[[1,0,0], [0,1,0], [0,0,1]]
is pretty obvious.
Compare what's comparable:
[[1,0,0], [0,1,0], [0,0,1]]
vs
"1 0 0;" "0 1 0;" "0 0 1"
or
""" 1 0 0; 0 1 0; 0 0 1 """
[[1,0,0], [0,1,0], [0,0,1]] vs "1 0 0; 0 1 0; 0 0 1"
The difference in (nonwhitespace) chars is 19 vs 25, so the "shorthand" doesn't seem to save that much.
Well, it's easier to type "" (twice the same character) than [], and you have no risk in swapping en opening and a closing bracket. In addition, you have to use AltGr on some keyboards to get the brackets. It doesn't boils down to a number of characters.
Just my €0.02,
It's the year of the notebook.
notebooks are reusable. notebooks correctly align the brackets in the second and third line and it looks pretty, just like a matrix
(But, I don't have to teach newbies, and often I even correct whitespace on the commandline, because it looks ugly and I will eventually copy it to a script file.)
Josef no broken windows! well, except for the ones I don't feel like fixing right now.
 C
On Fri, Jul 18, 2014 at 10:05 AM, Alan G Isaac alan.isaac@gmail.com
wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not
just advocate using
a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
fwiw, Alan Isaac
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Jul 18, 2014 at 1:15 PM, Joseph MartinotLagarde < joseph.martinotlagarde@m4x.org> wrote:
In addition, you have to use AltGr on some keyboards to get the brackets.
If it's hard to type square brackets  you're kind of dead in the water with Python anyway  this is not going to help.
Chris
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph MartinotLagarde <joseph.martinotlagarde@m4x.org mailto:joseph.martinotlagarde@m4x.org> wrote:
In addition, you have to use AltGr on some keyboards to get the brackets.
If it's hard to type square brackets  you're kind of dead in the water with Python anyway  this is not going to help.
Chris
Welcome to the azerty world ! ;)
It's not that hard to type, just a bit more involved. My biggest problem is that you have to type the opening and closing bracket for each line, with a comma in between. It will always be harder and more error prone than a single semicolon, whatever the keyboard.
My use case is not teaching but doing quick'n'dirty computations with a few values. Sometimes these values are copypasted from a space separated file, or from a printed array in another console. Having to add comas and bracket makes simple computations less easy. That's why I often use Octave for these.
On Fri, Jul 18, 2014 at 5:04 PM, Joseph MartinotLagarde < joseph.martinotlagarde@m4x.org> wrote:
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph MartinotLagarde <joseph.martinotlagarde@m4x.org mailto:joseph.martinotlagarde@m4x.org> wrote:
In addition, you have to use AltGr on some keyboards to get the brackets.
If it's hard to type square brackets  you're kind of dead in the water with Python anyway  this is not going to help.
Chris
Welcome to the azerty world ! ;)
It's not that hard to type, just a bit more involved. My biggest problem is that you have to type the opening and closing bracket for each line, with a comma in between. It will always be harder and more error prone than a single semicolon, whatever the keyboard.
My use case is not teaching but doing quick'n'dirty computations with a few values. Sometimes these values are copypasted from a space separated file, or from a printed array in another console. Having to add comas and bracket makes simple computations less easy. That's why I often use Octave for these.
my copy paste approaches for almost quick'n'dirty (no semicolons):
given:
a b c
1 2 3
4 5 6
7 8 9
(select & CtrlC)
pandas.read_clipboard(sep=' ')
a b c
0 1 2 3
1 4 5 6
2 7 8 9
np.asarray(pandas.read_clipboard())
array([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]], dtype=int64)
pandas.read_clipboard().values
array([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]], dtype=int64)
arr = np.array('''\
1 2 3
4 5 6
7 8 9'''.split(), float).reshape(1, 3)
the last is not so quick and dirty but reusable and reused.
Josef
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 18 Jul 2014 18:06, "Alan G Isaac" alan.isaac@gmail.com wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not
just advocate using
a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9"))
It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say that the reason why such proposals miss the point is that there are introductory settings where one would like to explain as few complications as possible. In particular, one might prefer *not* to discuss the existence of a matrix type. As an additional downside, this is only good for 2d, and there have been proposals for the new array builder to handle other dimensions.
Going through np.mat also fails on the metagoal, which is to remove reasons for people to prefer np.matrix to np.ndarray, so that eventually we can deprecate the former without harm.
As far as this goal goes, it's all very well for some of us to say that users should toughen up or whatever, but it's useless: they'll just ignore you and use np.mat because it's easier. And then we have even more of a mess to clean up later.
n
On Fri, Jul 18, 2014 at 11:49 AM, Nathaniel Smith njs@pobox.com wrote:
Going through np.mat also fails on the metagoal, which is to remove reasons for people to prefer np.matrix to np.ndarray, so that eventually we can deprecate the former without harm.
As far as this goal goes, it's all very well for some of us to say that users should toughen up or whatever, but it's useless: they'll just ignore you and use np.mat because it's easier. And then we have even more of a mess to clean up later.
so maybe don't do anything new, and np.mat can produce an array at some point in the future when np.matrix is deprecated....
CHB
participants (15)

Alan G Isaac

Alexander Belopolsky

Charles G. Waldman

Chris Barker

Chris Barker  NOAA Federal

Daniel da Silva

Daπid

Eric Firing

Jacco Hoekstra  LR

josef.pktd＠gmail.com

Joseph MartinotLagarde

Mark Miller

Nathaniel Smith

Pauli Virtanen

Sebastian Berg