<div dir="ltr"><span style="font-size:10pt">On Sat, Jun 29, 2013 at 10:53 PM, Alan G Isaac <<a href="mailto:alan.isaac@gmail.com">alan.isaac@gmail.com</a>> wrote:</span><br>>>><br>>>> On 6/29/2013 3:00 PM, Nathaniel wrote:<br>

>>>><br>>>>> any objections to np.full?<br>><br>><br>><br>>> On Sat, Jun 29, 2013 at 9:55 PM, Alan G Isaac wrote:<br>>>><br>>>> Still curious:<br>>>> why isn't ``tile`` the right name?<br>

>>> (It already exists.)<br>><br>><br>>>>  >>> import numpy as np<br>>>>  >>> np.tile(3.0, (2,3))<br>>>> array([[ 3.,  3.,  3.],<br>>>>         [ 3.,  3.,  3.]])<br>

><br>><br>>>> If someone explained this, sorry to<br>>>> have missed it.<br>><br>><br>><br>> On 6/29/2013 5:25 PM, Robert Kern wrote:<br>>><br>>> It's implemented inefficiently.<br>

><br>><br>>> It is aimed at a different use case (building up arrays<br>>> from other arrays) that only incidentally, and thus<br>>> poorly, fulfils this one.<br>><br>><br>>> It has no relation to the empty()/ones()/zeros() line of<br>

>> functions. In particular, tile_like() would make no sense.<br>><br>><br>>> Being aimed at a different use case, it will be more<br>>> difficult to find for people who are not familiar with<br>>> numpy's entire API. It will be an isolated idiom rather<br>

>> than a natural completion of the existing APIs.<br>><br>><br>><br>><br>><br>> I do not understand this reply.<br>><br>> 1. efficiency: noted in my original post, and I believe<br>> it could easily be fixed.  Am I wrong?<br>

<br><div style>With more special cases, sure.</div><div><br></div><div>> 2. use case: I assume this is the efficiency argument in<br>> a new guise?<br><br>No. It does explain the inefficiency, though.<br><br>> 3. grammar: if there were an obvious choice, this discussion<br>

> would have ceased long ago: ``tile`` is as good as any for<br>> this reason,<div><br></div><div>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.<br>

</div><div><br></div><div>> and I don't see the problem with ``tile_like``.<br><br><div style>It makes no sense except in the scalar case.</div><div><br></div><div>> 4. isolated idiom (i.e., 3. again): the only way around this<br>

> is to use ``constant``, which is in use in other languages.<br>> This has been vetoed as confusing terminology.<br>> The problems with each other suggestion have been covered<br>> extensively in this and related threads.<br>

<br></div><div style>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:</div>

<div style><br></div><div style>  np.ones(shape) * value</div><div style><br></div><div style>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.</div>

<div style><br></div><div>--<br>Robert Kern<br></div></div></div></div>