Problem on Variable.grad.data?
<SCODE>print(x.grad)
None

dir(x.grad)
['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']
<ECODE> Whereas is it working fine on my personal computer , on PyTorch ‘0.1.9+aaf41c6’. Is this an issue or there is something that i Don’t know about? Thanks a lot !
D_Kay
Hi, <SCODE>x=torch.Tensor(5,5).normal_()
x=Variable(x,requires_grad=True)
print(hasattr(x.grad, "data")) # prints False
x.add(1).sum().backward()
print(hasattr(x.grad, "data")) # prints True
<ECODE>
albanD
Is there a way to easily init the gradient buffer ? I also wondered where I can get the latest patch notes? The last time I checked on github,  there were only the notes for the 0.1.9 version Thanks again !
D_Kay
Hi, For the 0.1.10 release note, I think Soumith is currently working on them and they should be on github soon.
albanD
I managed to get access to it by doing a “dummy” backprop in the _ _init _ _. That’s a quick and dirty solution, and I’m open to better ones. Thanks again !
D_Kay
No, you can’t initialize it manually, but I don’t really see why would you need to do that (it’d be a tensor of zeros anyway). You can still access and modify the gradient, but only once the backward has been computed. Doesn’t this work for you: <SCODE>output = model(input)
loss(output).backward()
model.weight.grad.data # not None anymore. Can be modified
<ECODE>
apaszke
ypxie
I see, that’s actually a good point, we haven’t thought about that. We’ll have to solve it somehow
apaszke
How did you perform the “dummy” backprop?
Ilya_Kostrikov
I used the following workaround. <SCODE>        for shared_param in  shared_model.parameters():
            if not hasattr(shared_param.grad, 'data'):
                dummy_loss = 0
                for this_para in shared_model.parameters():
                    dummy_loss += torch.mean(this_para)
                dummy_loss.backward()
                break
<ECODE>
ypxie
So when exactly is it a problem? How are you implementing A3C? Are you sharing the main model parameters or does your training loop body look like this: <SCODE>loss = fn(input)
loss.backward()
copy_grads_to_shared_model(model, shared_model)
shared_model_optimizer.step()
copy_params_to_local_model(model, shared_model)

<ECODE>
apaszke
apaszke
D_Kay
ypxie
apaszke
Thank you~ For the safe issue, i noticed that DM’s paper explicitly said they don’t put a lock on the shared weights. For your solution to the shared grad to pytorch-a3c. <SCODE>def ensure_shared_grads(model, shared_model):
    for param, shared_param in zip(model.parameters(), shared_model.parameters()):
        if shared_param.grad is not None:
            return
        shared_param._grad = param.grad
<ECODE>
ypxie
jingweiz
So what’s the verdict here? Should we just remove the if condition? Because I can see no reason for the check. From what I’ve seen _grad is always accessible, and the global parameter grad is always updated to match the local, after I remove the if condition.
longhuei
jhliew
xuehy