Create IsNaN-20 and IsInf-20

[justinchuby]

Description

Create IsNaN-20 and IsInf-20 to include all floating point types. Note that even though float8 types like e4m3fnuz do not have representation for infinity, we still define the operator on these types so that the operators can be conveniently applied on all floating point types.

Checklist

• Update the opset in defs.cc
• Move the old definition of old.cc
• Add the operator to onnx/defs/operator_sets.h
• Create node tests
• Disable the tests in test_backend_onnxruntime.py
• Create reference implementation
• Update version converter
• Create shape inference and checker tests
• Build docs

Motivation and Context

Fixes #5260

[xadupre]

About isinf, e4m3fnuz has no infinite value. Should we exclude it or return false ? Same goes with e5m2fnuz.

[justinchuby]

About isinf, e4m3fnuz has no infinite value. Should we exclude it or return false ? Same goes with e5m2fnuz.

I think we should return False. Do we know how other frameworks handle them?

[xadupre]

Only e5m2 has infinite values and CUDA uses this type to compute the gradient. The only operator available is Gemm so there is no division involved and the default behaviour is to saturate the value to the maximum. I assume nan cannot appear with this only operation.

[gramalingam]

I agree that for the float-8 variants that do not have an infinity value, IsInf should always return false. (While this is a redundant op for this type, it may still be helpful in defining functions that work generically for all floating-types.)

[justinchuby]

I may need to exclude test_isinf_float16_cpu (but it was added already?)

[liqunfu]

I may need to exclude test_isinf_float16_cpu

Why other tests for new and updated have been passing? And why it was passing before?

[justinchuby]

Why other tests for new and updated have been passing? And why it was passing before?

It should have been skipped (and should pass) already. I am not very sure.

[justinchuby]

Everything now fails though @liqunfu @jcwchen Should opset20 tests be auto skipped or do I need to manually add skips?

[jcwchen]

Everything now fails though @liqunfu @jcwchen Should opset20 tests be auto skipped or do I need to manually add skips?

Which test failure are you referring to? The latest commit seems to complain the node backend data is inconsistent. I would suggest you recreate those node backend data from scratch (manually running command) again.

[justinchuby]

@jcwchen Looks like the new test is not skipped automatically? https://dev.azure.com/onnx-pipelines/onnx/_build/results?buildId=52121&view=logs&j=825fcbdb-febe-56c2-0b31-e8b200b321eb&t=46007089-1c35-5679-e243-e8ae35eaeec6&l=656

[jcwchen]

@jcwchen Looks like the new test is not skipped automatically? https://dev.azure.com/onnx-pipelines/onnx/_build/results?buildId=52121&view=logs&j=825fcbdb-febe-56c2-0b31-e8b200b321eb&t=46007089-1c35-5679-e243-e8ae35eaeec6&l=656

I thought https://github.com/onnx/onnx/blob/main/onnx/test/test_backend_onnxruntime.py should be covered by ORT_MAX_ONNX_OPSET_SUPPORTED_VERSION, but it seems it doesn't and we need to manually filter new versions as https://github.com/onnx/onnx/blob/main/onnx/test/test_backend_onnxruntime.py#L234-L254. It might make sense that we enable ORT_MAX_ONNX_OPSET_SUPPORTED_VERSION for test_backend_onnxruntime.py as well to save some effort. cc @xadupre for inputs. Thanks!