4 ms·
> Support for more platforms and languages, and improved compatibility and parity between these components via standardization on exchange formats and alignment
by kodablah 8y ago
> Support for more platforms and languages, and improved compatibility and parity between these components via standardization on exchange formats and alignment of APIs.
Does this mean we can get a pure C API for training and running? Right now, IIRC you can only train in Python and C++ which ignores a large part of the programming community. If not a pure C FFI API, what is the approach being taken?
- nine_k 8y agoHow hard would it be to provide and maintain a C++-to-pure-C API adapter? Serious question.
- kodablah 8y agoI am not sure as I haven't done it, but this has been attempted at a generic level in many languages. E.g. there are multiple cpp-to-rust bridges. That's essentially how most Qt bindings work. Most of the trouble is probably around inheritance, visibility, etc. Well, that and the "provide and maintain [...] adapter" outside of the core supporting library authors has its own upkeep challenges.
- danieldk 8y agoThe C API permits training and running. But you have to define and serialize the graph in Python (or C++). (Of course, you could also write Tensorflow protobuf directly, but that would be tedious.)
- kodablah 8y agoPardon my naivete, so at some point when not reusing others' graphs/models, to get the most out of TF you are basically forced to use one of those two languages? With TF 2 claiming more platforms/languages, will this no longer be the case?