I have an algorithm which looks prettier when written assuming row-major order. To ensure the code looks pretty and it also runs fast on Julia’s native column-major arrays, I simply used the Adjoint object. It works great and it is both fast and the code looks nice. However, the speedup was lost when I ran it on copies of my arrays. Personally, I got to fix that simply by using deepcopy, and it is truly not a problem, but the behavior of copy surprised me.
This does not seem to be a question of shallow copy vs deep copy, right? It is more of a question related to the fact that copy implicitly runs collect on the object it is copying? This sound counterintuitive to me. Is there any rationale behind it, or is it more of a random historic fact?
In any case, I wonder what was the rationale: it seems more useful and intuitive to use collect or Array for materialization and have copy make a straight copy?
That question seems weird to me, as it can be asked of any functionality. Here is of the top of my head:
First and foremost, the whole point of LinearAlgebra.Adjoint is that it is lazy-ish, which permits certain optimizations. Otherwise we would just always use an explicit transpose. It is also the way to create a row-major matrix in Julia, which is important for efficient use of CPU cache by some algorithms.
the copy is of use for benchmarks of in-place operations
or for Monte Carlo simulations involving states stored in such an object
purely for consistency purposes: copy changing the type of an object seems like a weird contract
The interface of copy is mostly a convention, but generally if the argument is a wrapper that provides a “view” (eg Adjoint, PermutedDimsArray, SubArray), would you expect that it copies the parent and makes a similar view?
This may be a reasonable use case in some contexts, but that’s not how it works currently — maybe finding a different name for it would be the best way forward, instead of breaking copy.
In the meantime, you can copy the parent if you want to modify an object like this.
Yeah, I did expect it would copy the parent and make a similar view. I see how this can go wrong if the parent is much bigger.
The status quo now makes sense to me (the current convention about copies of views). It is certainly not an intuitive convention to me, but I can hardly claim some universal opinion here.