Jameson said if you're using subarrays, you can't count on it; I said if
they're both arrays, then you can rely on it (unless you've done something
sneaky). So depending on the types, either could be true.
In my personal opinion, the risk of memory sharing is quite a lot lower, in
practice, than Jameson's comment might have suggested. Unless I'm missing
something, in common usage there are three main situations where this is an
issue:
- reshaping (reshape, vec, etc)
- reinterpret
- allocation, e.g., mistakenly initializing a Vector{Vector{T}} with the same
underlying array for each element.
The first two don't currently return views, presumably because views don't
currently have the performance we want them to have. But I agree it might
become less confusing when we can return a view. Of course, once we switch to
returning views from indexing operations (rather than copies, like we
currently do), there will be new cases that might cause confusion.
--Tim
On Wednesday, April 23, 2014 11:51:56 AM Ethan Anderes wrote:
> Ok, I'm trying to reconcile Jameson's suggestion to generally assume an
> overlap, and Tim's to expect no overlap with arrays if pointer(a) !=
> pointer(b). Doesn't this imply that pointer(input) == pointer(output) a
> typical array function? With subarray's I fully expect sharing memory, just
> by the type of the output. I guess I had hoped that vec would have returned
> an array-view type or sub-array type to indicate what is happening.
>
> Side note: I've been preaching Julia to everyone I meet. I usually start the
> sermon with "when you start using Julia it will initially behave/feel very
> much like R or Matlab, but then when you need the full power of a fast
> modern language it is there for you". Can I really say the first part of
> the sermon if I need to tell them to generally expect outputs sharing
> memory with inputs (which, to my knowledge, is very different from how
> matlab and R behave)?
>
> I hope I'm not sounding critical (cuz I love the language). Mainly, I want
> to really understand how things work so I can better sell it to students
> and colleagues.
>
> Cheers,
> Ethan
