Open OuHangKresnik opened 5 years ago
Actually in this scenario, this tensor has a dimension of 0. I do believe this unusual situation needs more than a few line of code here
Thanks for pointing out the issue. The bug should have been fixed in 6b884.
The logic for new_weight is that TASO will always allocate a device memory for the new weight. If weight_initial is provided, the allocated memory will be initialized using the given value.
The logic should work for 0-d tensors as well, though we haven't explicitly test TASO with 0-d tensors. Let me know if you observe any other issues with 0-d tensors.
Thank you for your quick fixes.
noop.cc: create_weight, there is an assertion as well.
I have replaced the assertion in noop.cc to a warning message in commit 49e804e8.
Presumably, when TASO encounters an uninitialized weight tensor, it is likely due to a bug in previous layers, and we should report a warning message to users.
In ops.cc method new_weight, current logic is when weight_initial != NULL, then allocate_memory, else weight_ptr would be null ptr.
I don't know whether this logic is what we wanted, but there is an exception about it.
When look into ops_cudnn.cu:allocate_memory, there is a null condition inside actually.
So I think even we don't check weight_initial in ops.cc:new_weight, the logic still holds and no exception.