Replies: 1 comment
-
As most ML models are trained using 32-bit floats, in practice I wouldn't expect this to be an issue, because they'll be floats when they come out of the C code underneath whatever python library created the model, and then represented as doubles in python (which can represent all 32-bit floats exactly) and then coerced back into floats when stored in the protobuf. Does this actually cause any skew in real code? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi. As you may know, the precision of floating point attributes can be hurt when a graph is created by using ONNX python helper. This can degrade the accuracy of a model because floating-point values calculated at training cannot be passed to ONNX correctly.
The following is a simple example to produce this problem.
This example maps string values "A", "B", "C" to 2.0, 3.0, and 4.0 respectively. Any other string value is mapped to 1.1 (default_float). However, the precision of the default float value is corrupted in the ONNX file (label_encoder.onnx) as follows.
This is because the float type in Python is the double type in C/C++ as reported in an issue of protocol buffer (protocolbuffers/protobuf#4569).
Setting an environment variable PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION to python (default is cpp) can fix this problem if the loaded model is used by only Python runtime or compiler. However, this problem still exists when a runtime or compiler is implemented in C/C++ like ONNX Runtime.
Possible solutions are:
Is there any good solution?
Beta Was this translation helpful? Give feedback.
All reactions