[Numpy-discussion] numpy.filled, again

[Alan G Isaac]

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

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

3. grammar: if there were an obvious choice, this discussion
would have ceased long ago: ``tile`` is as good as any for
this reason, and I don't see the problem with ``tile_like``.

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.

Honestly, I don't have a dog in this race.  It just seems
that ``tile`` already exists, is easily fixed to do what is
wanted (or is this wrong?), and is tremendously easy to
remember once seen.

Cheers,
Alan Isaac