Framework Ops vs Raw Ops

In Python TensorFlow, there are some OPs defined in the Python Layer, and some defined in the C-api layer. I have been tasked to see how Java TensorFlow might want to handle this.

I have run some experiments with creating a FrameworkOperatorProcessor class in tensorflow-flow-generator and a couple of architectures present themselves. This class is basically a copy of OperatorProcessor with some tweaks.

The approaches seem to dictate generating a new class in tensorflow-framework, that I named FOps for now.

1. The first approach is to have FOps subclass org.tensorflow.op.Ops, that is generated in tensorflow-core-api. However, this leads to potential problems with name clashes with the methods and groups already in Ops. A prime example of this are the NN classes we added for Nn and NnRaw (SoftmaxCrossEntropyWithLogits<T> softmaxCrossEntropyWithLogits() has the same signature in both generated classes.) This option requires changing Ops from a final class to non-final so that it can be inherited.

2. A second approach is to use the delegate pattern, and have FOps hold an internal reference to Ops, and you could call methods on each as required. For example,

FOps ftf = FOps.create(graph);
ftf.math.tensordot(); // framework op
ftf.getOps().math.mul();  // raw op

3. Keep both totally separate from each other. This may potentially allow reuse of the existing OperatorProcessor. It may be more cumbersome to the programmer user.

4. Another option, that I haven't thought of yet.

I welcome thoughts on this.

Commencez par lire l’OperatorProcessor existant dans tensorflow-flow-generator et comparez-le au FrameworkOperatorProcessor proposé. Examinez les classes Ops, Nn et NnRaw générées dans tensorflow-core-api et tensorflow-framework. Le travail est terminé lorsqu’une approche pour exposer les opérations de framework et raw en Java a été sélectionnée et documentée.