On Mon, Jul 7, 2014 at 1:58 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Mon, Jul 7, 2014 at 3:28 PM, Sebastian Berg
> <sebast...@sipsolutions.net> wrote:
> > On Mo, 2014-07-07 at 09:50 -0400, josef.p...@gmail.com wrote:
> >>
> >> On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg
> >> <sebast...@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
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
