w3c/machine-learning-workshop

JS Operator overloading for Machine Learning

Opened this issue · 3 comments

@cynthia raises in his presentation a limitation of JavaScript for ML processing:

Due to the current limitations of JavaScript such as the lack of operator overloading it makes it challenging to implement an ergonomic API for vector matrix or tensor operations on the web platform.

There is an active Stage 1 proposal in TC39 around operator overload, including for matrix computations.

Can the various ML frameworks people comment on how important this is for the ergonomics of their APIs? @jasonmayes @teropa @EmmaNingMS @shiffman @annxingyuan @wangqunbaidu

I also wonder whether taking into account operator overloading has impact on how WebNN should be designed given that it itself provides multiple hardware-accelerated operators which would be useful well beyond the pure ML context. @huningxin has this been discussed at all in the context of WebNN design?

I also wonder whether taking into account operator overloading has impact on how WebNN should be designed

I understand the JS operator overloading would simply WebNN graph building code. For instance, the code of today's WebNN example

// intermediateOutput1 is the output of the first Add operation.
const intermediateOutput1 = nn.add(constant1, input1);

// intermediateOutput2 is the output of the second Add operation.
const intermediateOutput2 = nn.add(constant2, input2);

// output is the output tensor of the Mul operation.
const output = nn.mul(intermediateOutput1, intermediateOutput2);

could be simplified into

const output = (constant1 + input1) * (constant2 + input2)

adding @wchao1115 @gramalingam @RafaelCintron @pyu10055 @dsmilkov @nsthorat and @anssiko for thoughts and visibility.

In tensorflow.js we use chained API to improve usability of the API, with @huningxin example, it would look like this:

constant1.add(input1).mul(constant2.add(input2))

Obviously this does not look as elegant as the operator overloaded version, but from users point of view, they want to have a consistent API. IMO Operator overload can solve simple use cases, but you will still need some functions to represent more complex ops, as well as additional parameters.

I'd be willing to help with bridging TC39 folks to see what can be done to progress the proposal further.