[Numpy-discussion] numpy.filled, again

[Robert Kern]

On Sat, Jun 29, 2013 at 10:53 PM, Alan G Isaac <alan.isaac at gmail.com> wrote:
>>>
>>> On 6/29/2013 3:00 PM, Nathaniel wrote:
>>>>
>>>> any objections to np.full?
>
>
>
>> On Sat, Jun 29, 2013 at 9:55 PM, Alan G Isaac wrote:
>>>
>>> Still curious:
>>> why isn't ``tile`` the right name?
>>> (It already exists.)
>
>
>>>  >>> import numpy as np
>>>  >>> np.tile(3.0, (2,3))
>>> array([[ 3.,  3.,  3.],
>>>         [ 3.,  3.,  3.]])
>
>
>>> If someone explained this, sorry to
>>> have missed it.
>
>
>
> On 6/29/2013 5:25 PM, Robert Kern wrote:
>>
>> It's implemented inefficiently.
>
>
>> It is aimed at a different use case (building up arrays
>> from other arrays) that only incidentally, and thus
>> poorly, fulfils this one.
>
>
>> It has no relation to the empty()/ones()/zeros() line of
>> functions. In particular, tile_like() would make no sense.
>
>
>> Being aimed at a different use case, it will be more
>> difficult to find for people who are not familiar with
>> numpy's entire API. It will be an isolated idiom rather
>> than a natural completion of the existing APIs.
>
>
>
>
>
> I do not understand this reply.
>
> 1. efficiency: noted in my original post, and I believe
> it could easily be fixed.  Am I wrong?

With more special cases, sure.

> 2. use case: I assume this is the efficiency argument in
> a new guise?

No. It does explain the inefficiency, though.

> 3. grammar: if there were an obvious choice, this discussion
> would have ceased long ago: ``tile`` is as good as any for
> this reason,

I'm not referring to the names. ones()/zeros()/empty() are designed and
documented for similar use cases. You describe them in very similar ways:
"in order to make an array of a given shape and dtype filled with
(1s/0s/nothing in particular), use ones()/zeros()/empty()". You should
never describe tile() with a similar sentence. It happens to do something
similar given a very specific corner case, but that is not what the
function does and that is not what it is for.

> and I don't see the problem with ``tile_like``.

It makes no sense except in the scalar case.

> 4. isolated idiom (i.e., 3. again): the only way around this
> is to use ``constant``, which is in use in other languages.
> This has been vetoed as confusing terminology.
> The problems with each other suggestion have been covered
> extensively in this and related threads.

Again, I'm not talking about the name or our relationship to other
languages. Abusing tile() for this use case (which is *not* the use case it
is designed and documented for) would make it a numpy idiom, just something
that you have to be told and remember, much like the current idiom that we
recommend:

  np.ones(shape) * value

It is the complete API of tile() and the fact that it only happens to meet
the use case by abusing a small corner of its API that makes it use for
this an idiom. No matter what we name the function in the PR, it won't be
an idiom in the way I mean here.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130629/8750e0ab/attachment.html>