You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Module.to(ScalarType) has restrictions in PyTorch which aren't restricted in TorchSharp #1180
When calling Module.to(ScalarType) on a module, PyTorch has a restriction that the target dtype must be a floating point or a complex number. See here.
Also, when it gets a floating point type, PyTorch only moves parameters that are already a floating_point type to the new type. See for example here.
This is relatively trivial to add, would TorchSharp want to add the same restrictions?
changed the title [-]`Module.to(ScalarType)` has restrictions in `PyTorch` which aren't restricted in TorchSharp[/-][+]`Module.to(ScalarType)` has restrictions in `PyTorch` which aren't restricted in `TorchSharp`[/+]on Dec 7, 2023
Activity
[-]`Module.to(ScalarType)` has restrictions in `PyTorch` which aren't restricted in TorchSharp[/-][+]`Module.to(ScalarType)` has restrictions in `PyTorch` which aren't restricted in `TorchSharp`[/+]NiklasGustafsson commentedon Dec 8, 2023
Under the assumption that modules always participate in backprop, this constraint makes sense.
Fixing issue dotnet#1180