Different loss after iteration by same seed with different reduction way of nll_loss in gcn

jomei: <p>Hello, everyone:</p>
<p>I faced a problem about reduction way of nll_loss, which give me extremely different result by same seed in GCN.</p>
<p>I am using GCN to do binary text classification. First, I use class weight in the nll_loss as belowed. It gives me good result. As I used same seed, everytime I rerun the GCN, I can get the same result. I can check the log each iteration of loss is same.</p>
<pre><code class="lang-python">np.random.seed(args.seed)
torch.manual_seed(args.seed)
if args.cuda:
    torch.cuda.manual_seed(args.seed)

x_class = y.sum(dim=0).float()
z_weight = (1.0/x_class)*x_class.sum(0)/2.0
y = y.max(1)[1].type_as(labels)
return F.nll_loss(preds, y, z_weight)
</code></pre>
<p>But when I changed the nll_loss to reduction “none”, although the loss return is also same as above at the beginning, which value is 0.7351 at the first time, it will show different result after multi iteration at the end.</p>
<pre><code class="lang-python">x_class = y.sum(dim=0).float()
z_weight = (1.0/x_class)*x_class.sum(0)/2.0
y = y.max(1)[1].type_as(labels)
loss_pre = F.nll_loss(preds, y, reduction='none')
final_weight = z_weight[y]
return (loss_pre * final_weight).sum() / final_weight.sum()
</code></pre>
<pre><code class="lang-auto">#original loss
Epoch: 0001
 | loss: 0.7351
Epoch: 0002
 | loss: 0.6355
Epoch: 0003
 | loss: 3.2794
...
Epoch: 0010
 | loss: 0.6107
...
Epoch: 0200
 | loss: 0.0207

#loss of reduction none
Epoch: 0001
 | loss: 0.7351
Epoch: 0002
 | loss: 0.6355
Epoch: 0003
 | loss: 3.2797
...
Epoch: 0010
 | loss: 0.6097
...
Epoch: 0200
 | loss: 0.0239
</code></pre>
<p>Could anyone give some help? Thanks indeed.<br>
My environment is Python 3.6.9, pytorch 1.3.0 with CPU.</p>

ptrblck: <p>Are both approaches deterministic in isolation? I.e. are you getting the same results if you rerun the <code>reduction='none'</code> code?<br>
If so, then I think the difference between both approaches could come from a different order of the reductions and thus accumulated small absolute errors due to the limited floating point precision.</p>

jomei: <p>Thanks your reply. <a class="mention" href="/u/ptrblck">@ptrblck</a><br>
Yes, the returned loss of two reduction way are same, which is 0.7351 at the first time.<br>
When I rerun the reduction with none, it always show 0.7351 at the first time.<br>
I confirmed it by using ipdb to check.<br>
But after several iteration, the loss began to differ.<br>
So,  How to fix the calculation order of reduction.<br>
The reason why I wanna convert to reduction of none, is that I wanna combine sample weight to existed class weight’s loss.</p>

ptrblck: <p>No, I meant to ask if the second approach executed multiple times is yielding the same results (not in comparison to the first approach).</p>

jomei: <p>Yes, I have modified my first reply. When I rerun the code with reduction of none in the same seed, it output the same result with loss from first iteration to the last iteration.<br>
In fact, when I guessed from the result of reduciton of none, it seems that it doesn’t fully cooperate the class weight info.</p>

googlebot: <p>try doing this segment on cpu, the issue is that some operators used during backward are non-deterministic, so gradients differ in re-runs; in particular, indexing/gathering with many-to-one element correspondence</p>

jomei: <p>Thanks for your reply. <a class="mention" href="/u/googlebot">@googlebot</a><br>
In fact I run these codes in CPU already, but it shows the result above.<br>
Besides that, I rerun the reduction of none serveral times with same seed, it prove the same result and same loss.<br>
From my observation for the result returned by reduction of none, it seems that it doesn’t cooperate the class weight info.<br>
So I wander is it a bug or other problem?</p>

googlebot: <p>Oh, then above answer is likely correct:</p>
<aside class="quote no-group">
<blockquote>
<p>If so, then I think the difference between both approaches could come from a different order of the reductions and thus accumulated small absolute erro</p>
</blockquote>
</aside>
<p>You’re either not looking beyond first 4 digits of loss, or differences only manifest in gradients.</p>
<p>Not sure how you’d “fix” that, and if you need to do adjustments to “mean” mode, you’d lose result identity anyway…</p>

jomei: <p>But I still think it’s not related to float precision, cause I observe from the result of reduction of none, it seems that it doesn’t cooperate the class weight info.<br>
I still don’t know how to calculate the loss under the none correctly…</p>

jomei: <p>Excuse me，</p>
<aside class="quote no-group" data-username="ptrblck" data-post="2" data-topic="106143">
<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/ptrblck/48/1823_2.png" class="avatar"> ptrblck:</div>
<blockquote>
<p>If so, then I think the difference between both approaches could come from a different order of the reductions and thus accumulated small absolute errors due to the limited floating point precision</p>
</blockquote>
</aside>
<p>Can I have the method to overcome such problem?<br>
Cause in my situation, the reduction of mean return a good result, however, the reduction of none return a totally bad result.<br>
If I wanna use the reduction of none to cooperate the sample weight, I must overcome the problem above.<br>
Appreciate for your help.</p>