Which levels of abstractions in C++ should be exposed to Go about gotorch HOT 3 CLOSED

Here are my thoughts:

• native function: yep and it's a must, because all operators are defined at this level and some of them not exposed in the next two levels. e.g. non "nn" ops, custom ops
• nn functional: nice to have and we should do it, the binding can save us a lot of works of reimplementing the logic with native functions in go.
• nn.module: nice to have but it's probably hard, because we need to make sure they interact well with go level torch.Module. e.g. In a model with mixed c++ module (exposed through the binding) and go torch.Module, how do we serialize them? if a c++ module takes another module as input (e.g. Sequential), how can we pass a go torch.Module to c++?

from gotorch.

Thanks for all the kindly reminders and suggestions! @bddppq

BTW, is it that

1. nn.module and nn.functional are all based on nn.function?
2. is https://github.com/pytorch/xla an alternative implementation of nn.function?

If so, is that we can have gotorch.nn and gotorch.nn.functional just like PyTorch, as long as they all call native functions, and in the future, we can simply replace the implementation of native functions to use https://github.com/pytorch/xla?

from gotorch.

We are now clear that we need to migrate three layers from PyTroch to GoTorch:

1. native functions: https://github.com/wangkuiyi/gotorch/blob/develop/doc/wrap_native_functions.md
2. Functionals in torch.nn.functional and Modules in torch.nn : https://github.com/wangkuiyi/gotorch/blob/develop/doc/develop_functionals_and_modules.md

from gotorch.