On Sun, Jul 6, 2014 at 6:06 PM, Eric Firing 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 Sun, Jul 6, 2014 at 10:59 PM, Eric Firing 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 July 2014 08:48, Jacco Hoekstra - LR 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 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 Mo, 2014-07-07 at 09:50 -0400, josef.pktd@gmail.com wrote:

On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg 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 1:58 PM, Nathaniel Smith wrote:

On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg 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 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

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 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 Fri, Jul 11, 2014 at 4:30 PM, Daniel da Silva 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]])

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]

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

On Sun, Jul 13, 2014 at 6:31 PM, Alexander Belopolsky 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

I greatly prefer "np.mat" to "np.arr" for this, FWIW On Fri, Jul 18, 2014 at 3:37 AM, Nathaniel Smith wrote:

On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman 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:37 AM, Nathaniel Smith wrote:

On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman 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

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

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

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 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 Fri, Jul 18, 2014 at 11:49 AM, Nathaniel Smith 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