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.

Beginne damit, den vorhandenen OperatorProcessor in tensorflow-flow-generator zu lesen und ihn mit dem vorgeschlagenen FrameworkOperatorProcessor zu vergleichen. Überprüfe die generierten Klassen Ops, Nn und NnRaw in tensorflow-core-api und tensorflow-framework. Als abgeschlossen gilt, wenn ein Ansatz für die Bereitstellung von Framework- und Raw-Operationen in Java ausgewählt und dokumentiert wurde.