rand(like!(M))
would read better than the current rand(similar(M))
It wins by 3 letters and 2 syllables.
EDIT: (thanks @fengyang.wang)
EDIT: how about shape
? I think that’s better than either similar
or like
(see post #10).
rand(like!(M))
would read better than the current rand(similar(M))
It wins by 3 letters and 2 syllables.
EDIT: (thanks @fengyang.wang)
EDIT: how about shape
? I think that’s better than either similar
or like
(see post #10).
You probably mean rand!(like(M))
.
It’s also closer to ones
and zeros
which are arguably its cousin.
Just curious: why you find it closer?
Length. like
, size
, ones
, zeros
are all similar in length and tend to be used for similar things. The word similar
doesn’t seem to fit in. (This whole response is a mouthful).
Couldn’t this just be a method of copy, maybe with a keyword argument to say to copy only the structure, not the entries?
What problem are we trying to solve here?
My original suggestion was simply to replace similar
with like
, as it is a better choice of keyword:
x like y
as opposed to x similar TO y
, i.e. TO
is required to make decent English, x similar y
grates.So it’s not really “solving a problem” per se. Unless the problem is “How to go about constructing the most elegant possible language?” in which case I think it is a minute step in the right direction.
I’m not saying it’s enough to act on it, but I do like it. But as @dpsanders noted, it would probably be most clear to just have it as a variant of copy.
Then how about shape
if we are just trying to copy the structure?
rand!(shape(M))
… that actually makes linguistic sense. i.e. You could understand that without prior Julia knowledge, whereas both like
and similar
are both misleading.
i.e. rand!(like(M))
may make sense, but like(M)
on its own doesn’t make sense. Because the thing it returns isn’t like M
, it is the shape of M
.
rand(size(M))
currently works just fine for this; it’ll default to Float64 elements but you can easily specify the element type you want with rand(T, size(M))
.
The biggest critique of similar
also applies to the name like
— it doesn’t really specify what parts of the “structure” are important and precisely in what regard it should be similar to the original array. At least some elements need to be mutable for the returned thing to be useful, but do all of them need to be? What type should be returned if the original array type doesn’t support the given shape? You’re really asking the original array to guess what data structure will be most efficient or most useful in the subsequent operations… which of course it cannot know.
Honestly, I don’t think similar
is all that useful when you’re writing non-library code. It’s typically simpler, more readable, and more efficient (in terms of the subsequent complexity) to just be explicit and ask for Array{T}(sz)
or use construct like rand(size(M))
above.
No it doesn’t work for this. That will create an Array
with that size. Not every AbstractArray
is an Array
.