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

[justinchuby]

Absolutely. Contributions are welcome and appreciated

[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

[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).