Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebML WG Teleconference – 27 June 2024 - Open issues and PRs #24

Open
anssiko opened this issue Jun 20, 2024 · 3 comments
Open

WebML WG Teleconference – 27 June 2024 - Open issues and PRs #24

anssiko opened this issue Jun 20, 2024 · 3 comments

Comments

@anssiko
Copy link
Member

anssiko commented Jun 20, 2024

We'll discuss open issues and review PRs based on your feedback:

Please suggest issue(s) and PR(s) you'd like to see discussed on this teleconference in this issue.

@a-sully
Copy link

a-sully commented Jun 24, 2024

I'd like to discuss webmachinelearning/webnn#567

@inexorabletash
Copy link
Member

While most feedback will probably require async review, there was some interest in making progress on webmachinelearning/webnn#647 and specifically webmachinelearning/webnn#647 (comment) so I can give a quick overview of the PR and its implications, and what the proposed next steps are. Hopefully that will generate some feedback.

@inexorabletash
Copy link
Member

inexorabletash commented Jun 27, 2024

Async update for webmachinelearning/webnn#647 "MLNumber" proposal

  • Some places that took a float or double argument/option now take MLNumber or MLFiniteNumber - a "variant" (union) of either a JS Number (equivalent to a C++ double) or BigInt (for full precision int64/uint64 use)
  • Places that took a float argument/option now take a double. These are all ops that only operate on float types, so no need for MLNumber. This follows web API best practices, and allows full precision conversion to float16 (float64 to float32 to float16 is lossy)
  • In all of these places, the input number is cast to the input/output operand data type when it is used.
    Casting algorithms are spelled out; latest discussion proposes we always have "clamp" semantics (i.e. no weird modulus wrapping), and never fail
  • Using "Number or BigInt" is novel here, but WebIDL experts agree it's reasonable. Note that all existing WebIDL/JS APIs that are designed to take a Number, or to take a BigInt, will throw if the other thing is passed - there is intentionally no silent conversion. So we are in novel territory here and should look for implementation and developer feedback.
  • Prototyping in https://chromium-review.googlesource.com/c/chromium/src/+/5466806 and some discussion about error cases, incorporated into the PR.
  • Note that Clarify the casting behavior from floating-point / signed integers <-> unsigned integers webnn#489 looks similar, but is about the explicit cast() op.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants