Add cpu op Pow, Expand, Cast, Shape, UpsampleV9

[28Smiles]

To get my Model working, I needed some more ops.

• Pow
• Expand
• Cast
• Shape
• UpsampleV9

I also "fixed" Slice to accept all number types, as the spec suggests.

I enabled the op-tests and also tested the runtime with my model.

[fs-eire]

The change looks good to me; 2 nits to take a look. Thanks for contributing to ONNX.js!

[fs-eire]

since the scales are dynamic now, should we check the length?

[28Smiles]

Should be resolved

[fs-eire]

is it equivalent to do BroadcastUtil.calc(output, x, (a, b) => b, true); ? if so we can do inplace broadcast

[28Smiles]

no, since the argument order is important and only the right hand side can be used for the inplace. Only a custom implementation or an extension of the BroadcastUtil would work. Correct me if I am wrong

[fs-eire]

Explanation of why "test_cast_DOUBLE_to_FLOAT" failed:

ONNX.js does not strictly using data types in ONNX - float/double is not treated differently (all numbers are double in javascript anyway) when creating a tensor, but their data types are different. Currently we bypass this problem by avoid using float64; but there should be a better way to support those types in future.

[28Smiles]

Explanation of why "test_cast_DOUBLE_to_FLOAT" failed:

ONNX.js does not strictly using data types in ONNX - float/double is not treated differently (all numbers are double in javascript anyway) when creating a tensor, but their data types are different. Currently we bypass this problem by avoid using float64; but there should be a better way to support those types in future.

But shouldn't this be the case the other way round?
test_cast_FLOAT_to_DOUBLE, float and double are the same, so output is float?
test_cast_DOUBLE_to_FLOAT, output should always be float?

Seems odd to me. Also test output for (test_cast_DOUBLE_to_FLOAT) is:

input tensor[0] check failed: expected type 'float64' but got float32

The test should expect a float, but expects a double. Most likey the two tests names are switched?

[fs-eire]

Explanation of why "test_cast_DOUBLE_to_FLOAT" failed:
ONNX.js does not strictly using data types in ONNX - float/double is not treated differently (all numbers are double in javascript anyway) when creating a tensor, but their data types are different. Currently we bypass this problem by avoid using float64; but there should be a better way to support those types in future.

But shouldn't this be the case the other way round?
test_cast_FLOAT_to_DOUBLE, float and double are the same, so output is float?
test_cast_DOUBLE_to_FLOAT, output should always be float?

Seems odd to me. Also test output for (test_cast_DOUBLE_to_FLOAT) is:

input tensor[0] check failed: expected type 'float64' but got float32

The test should expect a float, but expects a double. Most likey the two tests names are switched?

The test case (ONNX model) expects a float64 input tensor, but since "there is only one float type in ONNX.js" (described above) the input tensor is created as float32, which is a mismatch to the model's input type requirement.

[28Smiles]

Explanation of why "test_cast_DOUBLE_to_FLOAT" failed:
ONNX.js does not strictly using data types in ONNX - float/double is not treated differently (all numbers are double in javascript anyway) when creating a tensor, but their data types are different. Currently we bypass this problem by avoid using float64; but there should be a better way to support those types in future.

But shouldn't this be the case the other way round?
test_cast_FLOAT_to_DOUBLE, float and double are the same, so output is float?
test_cast_DOUBLE_to_FLOAT, output should always be float?
Seems odd to me. Also test output for (test_cast_DOUBLE_to_FLOAT) is:

input tensor[0] check failed: expected type 'float64' but got float32

The test should expect a float, but expects a double. Most likey the two tests names are switched?

The test case (ONNX model) expects a float64 input tensor, but since "there is only one float type in ONNX.js" (described above) the input tensor is created as float32, which is a mismatch to the model's input type requirement.

Guess i missed the "input" in the error message