lgusm:

The only detail on your image that I could spot is the Support Vector Machine (SVM).


Just to play a little bit with the concept we accepted a tutorial
  
      

      keras.io
  

  
    

Keras documentation: A Quasi-SVM in Keras 5



  

  
    
    
  

  



if the layer you need is not available directly, you can customize or create your own with the same API.

I think this is the main point.
More in general, to extend the evaluation over that specific cheat-sheet, you could need to write a custom op inside a brand new layer and the compositional performance of you python code for the TF ops  is too slow to practically train a model.
In that case, as Keras is a standalone python-only project, you need to add your own custom ops/kernel in TF, in TF Addons or to maintain it in your own repository.
This could create a management overhead in the case you will need more general model portability (TFlite, TPU, other GPUs) etc.
We can always collaborate with the XLA/MLIR team to better improve the compiler stack lowering driven by new model requests (IMHO this process could be driven by TF model garden and TF Addons with a better interplay with the compiler stack team).
Just to make practical example for a quite popular operation like Deformable Convolution see:
  
    
    
    Deformable convolution and other custom ops MLIR
  
  
    Recently we had a refresh over a Deformable convloution WIP PR in Addons. 
I’ve cherry-picked this as an example as this requires us to maintain almost 3k lines of new code in the repository. 
This is maintainer-ship overhead is also quite similar to what we have with other custom kernels PRs. 
As Addons is one of the few Ecosystem repositories to support custom (c++) ops and the related CI infra it is quite normal that we have this kind of proposed PRs. 
But as the codeownership of these compon…