Short-hand array creation in `numpy.mat` style
The idea is that there be a short-hand 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 short-hand 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 row-vector?) Should there be some way to write 3d or higher-d arrays? -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
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 short-hand 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 row-vector?)
Yes, it is reasonable that a semicolon should trigger 2d.
Should there be some way to write 3d or higher-d 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 off-the-cuff 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 off-the-cuff 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: numpy-discussion-bounces@scipy.org [mailto:numpy-discussion-bounces@scipy.org] On Behalf Of Alexander Belopolsky Sent: maandag 7 juli 2014 6:30 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style On Sun, Jul 6, 2014 at 10:59 PM, Eric Firing <efiring@hawaii.edu<mailto: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 off-the-cuff 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/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, 2014-07-07 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Mo, 2014-07-07 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 copy-pasted text tables.) Josef
- Sebastian
Alan Isaac
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mo, 2014-07-07 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, 2014-07-07 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 copy-pasted text tables.)
Josef
- Sebastian
> Alan Isaac > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Mo, 2014-07-07 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, 2014-07-07 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 ("matlab-like array construction") np.sarr ("string array") np.parse -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
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, 2014-07-07 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, 2014-07-07 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 ("matlab-like 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 hard-code a few values, and it is true that making a list (or nested list) is quite verbose; one example are unittests. Having a MATLAB-style 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 colour-coded 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 matrix-type in. It is simply a very useful, short-hand way, probably a separate function, to make a 2D-array. If you think it’s ugly, don’t use it. But it certainly is faster to type it and former Matlab-users will love it as well. Just my 2 cts. From: numpy-discussion-bounces@scipy.org [mailto:numpy-discussion-bounces@scipy.org] On Behalf Of Alexander Belopolsky Sent: zondag 13 juli 2014 19:31 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Short-hand 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 triply-nested brackets... No-one'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
-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 triply-nested brackets...
No-one'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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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... -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
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 one-line 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 (non-Pythonic) input mode. Too much molly-coddling 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 (non-whitespace) 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 (non-Pythonic) input mode. Too much molly-coddling 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 (non-whitespace) 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Joseph Martinot-Lagarde 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 Martinot-Lagarde <joseph.martinot-lagarde@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 (non-Pythonic) input mode. Too much molly-coddling 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 (non-whitespace) 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jul 18, 2014 at 4:21 PM, Charles G. Waldman <charles@crunch.io> wrote:
Joseph Martinot-Lagarde 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 Martinot-Lagarde <joseph.martinot-lagarde@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 (non-Pythonic) input mode. Too much molly-coddling 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 (non-whitespace) 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde < joseph.martinot-lagarde@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 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org <mailto:joseph.martinot-lagarde@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 copy-pasted 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 Martinot-Lagarde < joseph.martinot-lagarde@m4x.org> wrote:
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org <mailto:joseph.martinot-lagarde@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 copy-pasted 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 & Ctrl-C)
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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 meta-goal, 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 meta-goal, 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 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
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 Martinot-Lagarde -
Mark Miller -
Nathaniel Smith -
Pauli Virtanen -
Sebastian Berg