Add isNaN and isInfinite operators

[fdwr]

Fixes #811. Since NaN and infinity are closely related concepts, I'm introducing both logical unary operators together for completeness.

partial interface MLGraphBuilder
{
    ...
+   MLOperand isNaN(MLOperand a, optional MLOperatorOptions options = {})
+   MLOperand isInfinite(MLOperand a, optional MLOperatorOptions options = {})
    ...
};

Mappings to backend functions:

Is not-a-number:

• numpy.isnan
• tf.math.is_nan
• torch.isnan
• onnx.ai.IsNaN
• DML_OPERATOR_ELEMENT_WISE_IS_NAN
• mil.ops.defs.iOS15.elementwise_binary.not_equal(a, a)

Is infinite:

• numpy.isinf
• tfm.optimization.math.isinf
• torch.isinf
• onnx.ai.IsInf
• DML_OPERATOR_ELEMENT_WISE_IS_INFINITY
• mil.ops.defs.iOS15.elementwise_unary.abs(..) &&
  mil.ops.defs.iOS15.elementwise_binary.equal(.., Infinity)

Possible question answers:

• Why name it "isInfinite" rather than "isinf" like Python API's? This isn't Python, it's closer kin to Javascript's isFinite function and Infinite constant, and general API naming guidelines favor whole words for readability.
• Why not support specific tests for positive infinity or negative infinity like ONNX? I'm not opposed to it, but I'm unsure the use case, most backends don't support it, and one could easily clamp the values before calling isInfinite to emulate it.
• Do we really need these functions? No - technically they can be emulated via existing logical operators, but backends may have more optimized forms of them, and their existence leads to better discoverability. One compromise would be to instead document a decomposition in the specification (similar to flatten and unsqueeze) in the Operator Emulation section.

Here are some example emulations:

function isNaN(val:Number): Boolean
{
    return val != val;
}

function isNotNaN(val:Number): Boolean
{
    return val == val;
}

function isNaNOrInfinity(val:Number): Boolean
{
    return (val * 0) != 0;
}

function isNotNaNOrInfinity(val:Number): Boolean
{
    return (val * 0) == 0;
}

---

Preview | Diff

[fdwr]

FYI @philloooo.

[huningxin]

I suppose isNan and isInfinite should only support "float32" and "float16" data types. You may want to add step to validate that.

[fdwr]

True. The alternative is that we take all data types, and for any non-float data types (int32, uint8...), WebNN just returns a tensor of all false 0's, which makes the operator more cleanly generic, but then I don't know any ML library that accepts integers to isNaN anyway, making it unlikely to reach WebNN.

Hmm, I don't like what we currently have where most operators visible show their data types in a table, but some operators instead bury data types inside algorithmic steps. Maybe I can cleanly promote this up into the existing table instead "Constraints for element-wise logical options"... ⏳

[huningxin]

but then I don't know any ML library that accepts integers to isNaN anyway, making it unlikely to reach WebNN.

Right. And the native framework may also reject integers for isNan and isInfinite, such as ONNX Runtime: IsNaN, IsInf

Hmm, I don't like what we currently have where most operators visible show their data types in a table, but some operators instead bury data types inside algorithmic steps. Maybe I can cleanly promote this up into the existing table instead "Constraints for element-wise logical options"

That's true. The latter was introduced for op categories with the intention of minimum change, see discussion at original PR: #657 (comment).

For this PR, I'd recommend to keep the change minimum with two options:

Option 1: Add a step into the "create an element-wise logical operation" algorithm, similar to validation step for "logicalNot":

1. If op is one of "isNan" and "isIfinite, then:
   1. If a ’s dataType is neither "float32" nor "float16 , then throw a TypeError .

Option 2: Add an optional allowedDataTyeps argument into "create an element-wise logical operation" algorithm (similar to "create an element-wise unary operation").

And add a step:

If allowedDataTypes is given and it does not contain input ’s dataType , then throw a TypeError .

With that, we can call "create an element-wise logical operation" with « "float32" , "float16" » for "isNan" and "IsInfinite". The validation step of logicalNot can be removed, we can call "create an element-wise logical operation" with « "uint8" » instead.