Pytorch 1.10 complex number change is horrible, please change it back

chenhao1umbc: <p>pytorch 1.10 says</p>
<blockquote>
<blockquote>
<blockquote>
<p>x = torch.tensor([1+2j])<br>
y = x.conj()<br>
z = y.imag<br>
print(z.is_neg())<br>
True<br>
z.add_(2)<br>
print(x)<br>
tensor([1.-0.j])</p>
</blockquote>
</blockquote>
</blockquote>
<p>This is anti-math! People who us complex number will not expect this behavior. Please change it back to the way in 1.9.</p>

albanD: <p>cc <a class="mention" href="/u/anjali411">@anjali411</a> who is working on this topic</p>

anjali411: <p>Hey <a class="mention" href="/u/chenhao1umbc">@chenhao1umbc</a> This is because the conjugation is now a view operation. So in this case, it’s expected that x, y and z will share memory. We made conjugation a view to take fuse it with matmul which now gives as much as 50% perf gain and 30% memory savings. In any case, if that doesn’t match your use case, I understand your concern and you can do the following things to get the old behavior:</p>
<pre><code class="lang-auto">y = x.conj_physical() # returns a conjugated tensor that does not share memory with x
z = y.imag 
</code></pre>
<p>or</p>
<pre><code class="lang-auto">y = x.conj()
if y.is_conj():
     y = y.resolve_conj() # can also use y.clone()
z = y.imag
</code></pre>

chenhao1umbc: <p>I can tell pytorch 1.10 doing this is for performance and memory saving. But for a user, especially engineer, we will not expect this behavior. Changing the z wil lead to x change, so I need a lot of “.clone()” to void math calculation wrong. This will not speed up anything… Both coding and performance are even slower.</p>
<p>Also, does the numpy people know .conj() using share memory will be faster? Of course, they know. But why didn’t they do it? Because it is anti-math, people using complex number heavily depend on math. If it is too different from math way, it is really hard for the user…</p>
<p>That is my a opinion. Maybe, I am wrong, but please think about it. Thanks.</p>

anjali411: <aside class="quote no-group" data-username="chenhao1umbc" data-post="4" data-topic="134874">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/chenhao1umbc/48/14836_2.png" class="avatar"> chenhao1umbc:</div>
<blockquote>
<p>Both coding and performance are even slower.</p>
</blockquote>
</aside>
<p>Actually the performance will be exactly the same since calling the new <code>torch.conj()</code> is a constant time operation.</p>
<p>However as I mentioned above, you can still get the old conj behavior if you use <code>torch.conj_physical</code> (out-of-place operation instead of a view operation)</p>

KFrank: <p>Hi Anjali!</p>
<aside class="quote no-group" data-username="anjali411" data-post="5" data-topic="134874" data-full="true">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/anjali411/48/20934_2.png" class="avatar"> anjali411:</div>
<blockquote>
<p>However as I mentioned above, you can still get the old conj behavior if you use <code>torch.conj_physical</code> (out-of-place operation instead of a view operation)</p>
</blockquote>
</aside>
<p>I do agree that the 1.10 behavior of <code>.conj()</code> is unexpected.</p>
<p>Would it make sense to rename the new <code>.conj()</code> to <code>.conj_view()</code>?  If<br>
so, I would then vote for leaving <code>.conj_physical()</code> as is to help make<br>
clear what is going on.  (Renaming <code>.conj_physical()</code> to <code>.conj()</code> might<br>
make use of <code>.conj()</code> the tempting default, tricking people into the<br>
aforementioned performance hit.)</p>
<p>Best.</p>
<p>K. Frank</p>