[Numpy-discussion] New numpy functions: filled, filled_like

[Matthew Brett]

Hi,

On Thu, Jan 17, 2013 at 10:10 PM, Benjamin Root <ben.root at ou.edu> wrote:
>
>
> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing <efiring at 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.

I'm a -0.5 on the new functions, just because they only save one line
of code, and the use-case is fairly rare in my experience..

Cheers,

Matthew