Add section on copy-view behaviour and mutability

[rgommers]

Closes gh-24

[amueller]

two comments from sklearn:
We use "out" a lot for inplace operations, for example cliping :
https://github.com/scikit-learn/scikit-learn/blob/8471c8389d794309b0b62a353e3af903acd48223/sklearn/ensemble/_weight_boosting.py#L278

or np.dot:
https://github.com/scikit-learn/scikit-learn/blob/8471c8389d794309b0b62a353e3af903acd48223/sklearn/linear_model/_base.py#L632

or np.log:
https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/neural_network/_multilayer_perceptron.py#L1099

Basically we have a lot of iterative algorithms and we can often reuse arrays from previous algorithms, and sometimes we have temporaries that we can overwrite when applying unary transformations.

Actually, looking into the repo, there's less places than I expected. We could probably use it in some other places as well. I wouldn't say it's a good pattern, but I don't know a way to replace it.

The other thing that was mentioned by @rgommers was that it might be possible to have pools of memory to reuse.
We considered doing that manually in scikit-learn/scikit-learn#18242
though then the gain in the end wasn't as big. I'm pretty sure there are other places where reusing temporaries could be beneficial an where we don't do it.

[apaszke]

It might be worth adding that there are libraries that do some form of tracing or abstract interpretation over a language that doesn't support mutation (to make analysis easier) and that in those cases implementing out= with correct handling of views might even be impossible to do.

[rgommers]

It might be worth adding that there are libraries that do some form of tracing or abstract interpretation over a language that doesn't support mutation (to make analysis easier) and that in those cases implementing out= with correct handling of views might even be impossible to do.

Thanks @apaszke, I've added that sentence. I assume these libraries include both JAX and TensorFlow today?

[rgommers]

Actually, looking into the repo, there's less places than I expected.

Glad to hear that:)

I wouldn't say it's a good pattern, but I don't know a way to replace it.

I think the "reusable buffers" feature could be used for the same thing in many cases, see example in data-apis/consortium-feedback#5. Where that's not the case is probably if you supply say a single row or column of an n-D array as the argument to out=. All your scikit-learn examples are supplying a complete array to out=, which should be expressable with "may use this buffer" rather than "must place result in this buffer".