[onert] Export dedicated OneRT data types to Python

[arkq]

NNFW types and numpy data types do not map one to one because NNFW has quantized types represented as uint8 or int16. Because of that it should be more efficient to export custom data type object which will map these two types.

Additionally, for convenience, dedicated types are exported in the top-level onert Python module, so one can use them as follows:

>>> import numpy as np
>>> import onert
>>> onert.
onert.bool          onert.dtype(        onert.float32       onert.int32         onert.native        onert.qint8         onert.tensorinfo(
onert.common        onert.experimental  onert.infer         onert.int64         onert.qint16sym     onert.quint8        onert.uint8
>>> np.array([2, 42, 42], dtype=onert.float32)
array([ 2., 42., 42.], dtype=float32)

ONE-DCO-1.0-Signed-off-by: Arkadiusz Bokowy [email protected]

[ragmani]

While reviewing this PR I noticed a couple of pre-existing issues (not introduced by these changes):

1. Quantization info
   There is currently no clear mechanism for handling quantization parameters (scale, zero_point). We probably need a consistent way to represent and preserve these attributes.

2. Data type mapping between onert and numpy
   At the moment, there is no standard mapping layer between onert.dtype and numpy.dtype. This means patterns like

np.array([1, 2, 3], dtype=onert.qint8)

will not work as expected. We likely need a bidirectional converter and clear usage rules so that dtype handling is both intuitive and reliable.

These are not regressions introduced by this PR, but they directly affect how usable the Python API works. If possible, could you also consider addressing them when binding tensorinfo?

[ragmani]

One additional request: after the changes in this PR, could you please check that the existing python examples still run correctly? Currently our CI does not include python API validation.

[arkq]

At the moment, there is no standard mapping layer between onert.dtype and numpy.dtype. This means patterns like
np.array([1, 2, 3], dtype=onert.qint8)
will not work as expected. We likely need a bidirectional converter and clear usage rules so that dtype handling is both intuitive and reliable.

I've been thinking about extending numpy with OneRT quantized types, so then numpy will be able to convert between floats, integers and quantized types. I've never done that before though, so I will have to investigate the pros and cons of such approach. Anyway, I think that then the API will be clear and simple because it would be possible to use all numpy operations (hopefully) on quantized tensors.

[ragmani]

I also looked into this and found NumPy’s ongoing work on a new dtype system relevant here:

https://numpy.org/neps/roadmap.html#extensibility

• NEP 41: outlines the shortcomings of the old monolithic dtype system and sets the direction for a modular, extensible design.
• NEP 42: proposes the new DType class hierarchy and APIs so that user-defined dtypes (e.g. quantized types with scale/zero-point) can be registered cleanly.
• NEP 43: extends universal functions (ufuncs) to integrate seamlessly with new dtypes, so user-defined dtypes can participate in NumPy operations.

All three are accepted or under discussion, but full implementation is still ongoing. Until this new dtype system is complete, introducing something like onert.qint8 directly into NumPy is not realistic.

Given this situation, I would suggest some practical options for now:

• Provide a mapping/conversion layer between onert.dtype and numpy.dtype in the Python bindings to ensure usability.
• If that turns out to be too complex or fragile, document it explicitly as a known issue and defer full support until NumPy’s extensible DType framework matures.

[ragmani]

LGTM

[arkq]

LGTM

Maybe we should wait with that PR (at least until the next week)? I will also look at the possibility to extend numpy data types, because I've seen somewhere (some time ago) that it is possible but maybe not very easy to do. I will investigate how complicated it would be right now (if possible at all). I will submit my investigation result here as well.

[ragmani]

That sounds like a good idea. I’ll look forward to your investigation.

[hseok-oh]

@arkq Please resolve conflicts