4 ms·
This is fun idea. With these kind of coding tasks you won't get any advantage of using differentiable programming paradigm, but it is a nice reminder how syntac
by mlajtos 5y ago
This is fun idea. With these kind of coding tasks you won't get any advantage of using differentiable programming paradigm, but it is a nice reminder how syntactically bad TensorFlow is. Code of any differentiable program should look identical to any non-differentiable program. Maybe a small annotation à la TorchScript [0] can be tolerated, but not reimplementing everything via function calls with overly descriptive names.
Btw link to GitHub repo is broken. Copy&pasting URL works.
[0] https://pytorch.org/docs/stable/jit_language_reference.html#language-reference https://pytorch.org/docs/stable/jit_language_reference.html#...
- tubby12345 5y agoTS won't work. Despite claims to the contrary the only way to use TS effectively is as a tracing aid.
- nevermore 5y agoFor comparison, here's a solution in torch with a torchscript derocator: https://gist.github.com/bethebunny/1319b96e412d6a68488b7cb35a095e35 https://gist.github.com/bethebunny/1319b96e412d6a68488b7cb35... IMO it's a huge advantage to be able to write torch model code that looks like how you'd write the same program in pure python, and still have them be serializable.
- albertzeyer 5y agoWell, almost exactly the same would work in TensorFlow as well. But the author choose to make the TF logic more explicitly visible, and use abstractions like tf.Module (like torch.nn.Module), the dataset, etc. I'm not sure this really makes so much sense. I guess this is more for just playing around.