[Numpy-discussion] numpy.filled, again
Alan G Isaac
alan.isaac at gmail.com
Sat Jun 29 17:53:48 EDT 2013
>> 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.
More information about the NumPy-Discussion