On Jan 17, 2013 8:01 PM, "Olivier Delalleau" <sh...@keba.be> wrote: > > 2013/1/17 Matthew Brett <matthew.br...@gmail.com>: > > Hi, > > > > On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > >> > >> On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root <ben.r...@ou.edu> wrote: > >>> > >>> > >>> > >>> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing <efir...@hawaii.edu> wrote: > >>>> > >>>> On 2013/01/17 4:13 AM, Pierre Haessig wrote: > >>>> > Hi, > >>>> > > >>>> > Le 14/01/2013 20:05, Benjamin Root a écrit : > >>>> >> I do like the way you are thinking in terms of the broadcasting > >>>> >> semantics, but I wonder if that is a bit awkward. What I mean is, if > >>>> >> one were to use broadcasting semantics for creating an array, wouldn't > >>>> >> one have just simply used broadcasting anyway? The point of > >>>> >> broadcasting is to _avoid_ the creation of unneeded arrays. But maybe > >>>> >> I can be convinced with some examples. > >>>> > > >>>> > I feel that one of the point of the discussion is : although a new (or > >>>> > not so new...) function to create a filled array would be more elegant > >>>> > than the existing pair of functions "np.zeros" and "np.ones", there are > >>>> > maybe not so many usecases for filled arrays *other than zeros values*. > >>>> > > >>>> > I can remember having initialized a non-zero array *some months ago*. > >>>> > For the anecdote it was a vector of discretized vehicule speed values > >>>> > which I wanted to be initialized with a predefined mean speed value > >>>> > prior to some optimization. In that usecase, I really didn't care about > >>>> > the performance of this initialization step. > >>>> > > >>>> > So my overall feeling after this thread is > >>>> > - *yes* a single dedicated fill/init/someverb function would give a > >>>> > slightly better API, > >>>> > - but *no* it's not important because np.empty and np.zeros covers > >>>> > 95 > >>>> > % usecases ! > >>>> > >>>> I agree with your summary and conclusion. > >>>> > >>>> Eric > >>>> > >>> > >>> Can we at least have a np.nans() and np.infs() functions? This should > >>> cover an additional 4% of use-cases. > >>> > >>> Ben Root > >>> > >>> P.S. - I know they aren't verbs... > >> > >> > >> Would it be too weird or clumsy to extend the empty and empty_like functions > >> to do the filling? > >> > >> np.empty((10, 10), fill=np.nan) > >> np.empty_like(my_arr, fill=np.nan) > > > > That sounds like a good idea to me. Someone wanting a fast way to > > fill an array will probably check out the 'empty' docstring first. > > > > See you, > > > > Matthew > > +1 from me. Even though it *is* weird to have both "empty" and "fill" ;)
I'd almost prefer such a keyword be added to np.ones() to avoid that weirdness. (something like "an array of ones where one equals X") Ray
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
