On Sat, Jun 29, 2013 at 10:53 PM, Alan G Isaac email@example.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.
- efficiency: noted in my original post, and I believe
it could easily be fixed. Am I wrong?
With more special cases, sure.
- use case: I assume this is the efficiency argument in
a new guise?
No. It does explain the inefficiency, though.
- 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.
- 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