ONNX Support: A proposal for Operator implementation

[imihalcea]

Hello,

I am currently unable to perform inference on my model because it uses the Sign operator, which isn't implemented yet in candle-onnx. I'd like to contribute by submitting a PR to implement this operator, but I'm finding the current code design a bit challenging.

At the moment, all operator code is contained within a single module with pattern matching on the operators. I feel that this approach may hinder scalability and make it more difficult to move towards a complete implementation of the specifications.

I propose introducing an OpsRegistry, which would be a map with the operator name as the key and the evaluation function as the value. The evaluation functions could reside in their own modules and include unit tests. This would simplify contributions, as contributors would only need to focus on the operator they want to implement without modifying the execution engine.

What do you think of this suggestion? Would a PR in this direction interest you?

Looking forward to your feedback.

Best regards,

Ionut

[AlpineVibrations]

This sounds good. As there are many issues asking for the missing Ops. Who do we ask to get this approved?

[LaurentMazare]

In its current shape candle-onnx is more of a proof of concept for candle usage than a fully fletched onnx library. As such I'm happy to see the new operations but don't feel that it's the right place to build a featureful onnx library so I would rather see this happen in an external crate if some folks want to give a try at doing this in a better way. If that works well, candle-onnx could probably be retired at some point.