<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi everyone, and thank you Ralf for carrying the flag in my absence. =D<br></div><div><br></div><div>Sebastian, the *primary* motivation behind avoiding detach() in PyTorch is listed in original post of the PyTorch issue:<br></div><div><br></div><blockquote><p>People not very familiar with <code>requires_grad</code> and cpu/gpu
Tensors might go back and forth with numpy. For example doing pytorch
-> numpy -> pytorch and backward on the last Tensor. This will
backward without issue but not all the way to the first part of the code
and won’t raise any error.<br></p></blockquote><div><br></div><div>The PyTorch team are concerned that they will be overwhelmed with help requests if np.array() silently succeeds on a tensor with gradients. I definitely get that.<br></div><div><br></div><div>Avoiding .gpu() is more straightforwardly about avoiding implicit expensive computation.<br></div><div><br></div><blockquote type="cite"><div>while others do not choose to teach about it. There seems very little<br></div><div>or even no "promise" attached to either `force=True` or `force=False`.<br></div></blockquote><div><br></div><div>NumPy can set a precedent through policy. The *only* reason client libraries would implement `__array__` is to play well with NumPy, so if NumPy documents that `force=True` should *always* succeed, we can expect client libraries to follow suit. At least the PyTorch devs have indicated that they would be open to this.<br></div><div><br></div><blockquote type="cite"><div>E.g. Napari wants to use it, but do the array-providers want Napari to use it?<br></div></blockquote><div><br></div><div>As Ralf pointed out, the PyTorch devs have already agreed to it.<br></div><div><br></div><div>From the napari perspective, we'd be ok with leaving the decision on warnings to client libraries. We may or may not suppress them depending on user requests. ;) But the point is to have a way of saying "give me a NumPy array DAMMIT" without having to know about all the possible array libraries. Which are numerous and getting numerouser.<br></div><div><br></div><div>Ralf, you said you don't want warnings — even for sparse arrays? That was an area of concern for you on the PyTorch discussion side.<br></div><div><br></div><blockquote type="cite"><div>And if the conversion still gives warnings for some array-objects, have we actually gained much?<br></div></blockquote><div><br></div><div>Yes.<br></div><div><br></div><div>Hameer,<br></div><div><br></div><blockquote type="cite"><div style="direction:ltr;">I would advocate for a `force=` kwarg but
personally I don't think it's explicit enough, but probably as explicit
as can be given NumPy's API.<br></div></blockquote><div><br></div><div>Yeah, I agree that force is kind of vague, which is why I was looking for things like `allow_copy`. But it is hard to be general enough here: sparse requires an expensive instantiation, cupy requires copying from gpu to cpu, dask requires arbitrary computation, xarray requires information loss... I'm inclined to agree with Ralf that force= is the only generic-enough term, but I'm happy to entertain other options!<br></div><div><br></div><div>Juan.<br></div></body></html>