Reference implementation of ONNX Reduce sum square is mismatch with ONNX Spec when noop_with_empty_axes == 1

[RunnerZhong]

Bug Report

Is the issue related to model conversion?

No

Describe the bug

When noop_with_empty_axes == 1 & axes is empty, in ONNX spec, it will return input tensor directly.
But in reference in onnx, it is mismatch. it returned np.square of the input tensor

System information

Reproduction instructions

Expected behavior

return input tensor directly

Notes

[amankshihab]

https://github.com/onnx/onnx/blob/d6f87121ba256ac6cc4d1da0463c300c278339d2/docs/Changelog.md?plain=1#L22221-L22222

The expected behavior is mentioned here as well.
Can I work on this? @justinchuby

[justinchuby]

Absolutely. Contributions are welcome and appreciated

[gramalingam]

This is complicated. Agree that there is a mismatch, but is the bug in the specification or implementation?

My personal interpretation is that this is a bug in the specification, not implementation, for the following reason: the attributes serve to define the set of axes being reduced: specifically, it is a flag to allow the empty list to indicate that all axes must be reduced (or that no axes must be reduced). Now, even if zero axes are reduced, it makes sense to compute the square. ReduceSumSquare is not actually a reduction-op: it is a reduction-op Sum applied to the square of the input.

I think the bug was in reusing the ReduceSum documentation for all ops ... it is correct for basic Reduction ops, but not ReduceSumSquare.

Of course, we can test with other backends/implementations (like onnxruntime, or even pytorch/tensorflow etc. IF they have such an option).

[justinchuby]

Following the discussion, I think it's reasonable to correct the spec. Out of curiosity, was there any reason you would expect the behavior to be different than the current one @RunnerZhong ?

[RunnerZhong]

I agree with below idea. So maybe we need to modify the spec of ops like ReduceSumSquare(ReduceLogSum, ReduceLogSumExp).

This is complicated. Agree that there is a mismatch, but is the bug in the specification or implementation?

My personal interpretation is that this is a bug in the specification, not implementation, for the following reason: the attributes serve to define the set of axes being reduced: specifically, it is a flag to allow the empty list to indicate that all axes must be reduced (or that no axes must be reduced). Now, even if zero axes are reduced, it makes sense to compute the square. ReduceSumSquare is not actually a reduction-op: it is a reduction-op Sum applied to the square of the input.

I think the bug was in reusing the ReduceSum documentation for all ops ... it is correct for basic Reduction ops, but not ReduceSumSquare.

Of course, we can test with other backends/implementations (like onnxruntime, or even pytorch/tensorflow etc. IF they have such an option).