New content: Add definition for shape broadcasting

[inexorabletash]

This change introduces a new section for Algorithms, following APIs, to collect algorithms referenced throughout the specification.

A section for Broadcasting is introduced, which defines broadcasting shapes and gives an explicit algorithm matching WebNN implementations of NumPy's General Broadcasting Rules. Definitions for "broadcastable" and "unidirectionally broadcastable" are introduced. The previous definition of "broadcast-shapes" is removed in favor of these new algorithms.

For #324, #462, and potentially #523.

---

Preview | Diff

[inexorabletash]

I'm still pretty hazy on definitions, so please look at this very skeptically.

Re: introducing a new "Algorithms" section - this is a pattern I've adopted from other specs. I thought I'd give a whirl here and see what everyone thinks. It's easy enough to drop and put these definitions anywhere else to keep the overall spec structure unchanged.

[inexorabletash]

Hold off on reviews, I was confusing unidirectional (mentioned in several places in the spec) and bidirectional (mentioned in the Chromium implementation). Fridays, am I right?

[inexorabletash]

Okay, this is updated to match the Chromium impl, I think. But... that may not be what's desired @a-sully mentions that unidirectional broadcasting seems specific to ONNX and other frameworks do things to work around this during export.

[a-sully]

AFAICT ONNX is an outlier in making a distinction between "unidirectional" and "multidirectional" broadcasting. This distinction is not made by:

• Numpy: https://numpy.org/doc/stable/user/basics.broadcasting.html
• PyTorch: https://pytorch.org/docs/stable/notes/broadcasting.html (which references Numpy)
• Tensorflow/XLA/StableHLO: https://www.tensorflow.org/xla/broadcasting (which also references Numpy, though it has some other restrictions)

The "unidirectional broadcastable" constraint of some ONNX ops (e.g. prelu()) requires workarounds when exporting from other formats to ONNX - like in this example of using TVM to export PyTorch to ONNX: pytorch/pytorch#70570 (comment). The folks on that issue discovered that the "unidirectional broadcastable" constraint for prelu() was not documented (which has since been fixed) and that there were inconsistencies between ONNX implementations (which... hopefully has also been fixed ¯\(ツ)/¯ )

Numpy's broadcasting rules are the clear standard across the industry and IMHO is the standard that we should expose to the web. It then becomes up to the user agent to ensure that the constraints of the underlying framework (e.g. unidirectional broadcasting for ONNX, lack of inferred broadcasting specifications for XLA) are satisfied.

[wacky6]

We follow Numpy broadcast rules for ops (in the chromium implementation), I think it's the golden "standard". +1 to adopt this throughout the spec (I didn't realize the spec matmul referred to an implementation defined broadcast 😱).

@a-sully mentions that unidirectional broadcasting seems specific to ONNX and other frameworks do things to work around this during export

Is ONNX unidirectional broadcast issue easy to workaround? The linked prelu() patch seems "easy enough".

Should we (from the spec's perspective) expect implementations (e.g. chromium DML backend)to do asid easy workarounds?

[huningxin]

LGTM with a comment, thanks much!

[huningxin]

@fdwr and @wchao1115 , please also take a look. Thanks!

[fdwr]

Thank you Josh.

[fdwr]

The unidirectional broadcastable constraint of some ONNX ops (e.g. prelu() requires workarounds when exporting from other formats ...

Huh, I would have presumed prelu was bidirectionally broadcastable too (TIL...). For operator behavior changes, I'd like it to be separate from this CR that's just adding definitions.

Is ONNX unidirectional broadcast issue easy to workaround? The linked prelu() patch seems "easy enough".

Yep, easy with a little reshape of leading 1's.

Should we (from the spec's perspective) expect implementations (e.g. chromium DML backend)to do asid easy workarounds?

Whichever broadcasting behavior we have for prelu, unidirectional or bidirectional, it's trivial either way for backends to insert leading 1's as needed (which the Chromium DML backend already does for DML, since DML expects elementwise tensor descriptions of each input to have been massaged to consistent rank first - any higher level concepts like broadcasting already resolved). In the worst case, backends can utilize whatever logic they have for expand to pre-expand tensors before forwarding them along.

[inexorabletash]

History was getting messy - I force-pushed a new squashed commit. It rolls in #564 to get the build working, but I'll rebase once that merges.

[fdwr]

I force-pushed a new squashed commit.

Josh: 🤔 Shoot, I'm unsure now if I merged your triangular CR via squash commit like I was supposed to. Appears it was a single commit.

Except larger branch integrations where we want to retain history, that's the general policy for cleaner history. Then the CR author doesn't need to ever explicitly squash their changes, because force pushes in GitHub yield this unfortunate result for reviewers to minimize the review delta since last time...

[fdwr]

LGTM. 👞✨

[inexorabletash]

No worries... I tend to squash locally, force-push, and always review the full diff anyway to see what the actual change is going to be. I'll try to refrain from squashing/force-pushing here though, going forward!

[fdwr]

One more tiny fix after re-review, which I'll just (per your earlier permission) submit and complete this. Thanks Josh.