>> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
