-
Notifications
You must be signed in to change notification settings - Fork 48
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
Behavior for numeric overflows/underflows/etc in algorithms #636
Comments
Process-wise, I'd propose that we hear from the editors and WG here, pick an approach we're happy with for now, then close this issue knowing that we might revisit later. CC: @fdwr @huningxin @zolkis |
This certainly makes sense.
Not yet sure about this. But interop is a primary concern, so all means helping (but not overspecifying) it should be considered.
Agreed with the notes, except I'd think more about the third note (and how to make those detectable with interop tests). |
Quick update here - @huningxin put together a spreadsheet enumerating places where the Chromium prototype does "checked math" to catch overflows (etc) and generates exceptions which aren't captured in the spec. The plan was to propose spec changes to capture those; once complete this issue can be closed. |
Some spec algorithms steps perform math that could overflow/underflow in implementations that do the arithmetic using particular types, such as
uint32_t
. This has been raised in #610 (comment) and #582 (comment) and probably elsewhere.There are a handful of nuances here:
https://source.chromium.org/chromium/chromium/src/+/main:components/ml/webnn/graph_validation_utils.cc;l=36 is an implementation example where a filter size is constrained to be a uint32 even though larger values could be supported (I think?)
I checked with some other spec experts. Approaches really vary depending on the spec's domain.
Most specs implicitly follow the guidance from Infra which says this on algorithm limits:
This seems like good practice to follow. On the other hand, some of the more fundamental specs (e.g. ECMA-262 - the JavaScript definition) need to specify in great detail how calculations are performed and deal with all of the fun edge cases. This is done with incredibly detailed algorithms and the use of helpers such as ℝ() (for converting to reals) and 𝔽() (for converting to doubles), along with consistent spec notation like ! (asserting that an expression will not throw) and ? (signaling that an expression may throw, and exceptions should propagate)
I think that for WebNN we have a range of options, and we may change our approach over time - e.g. start off without trying to capture this fine level of detail, but then introduce more rigor over time. Some options:
I'd lean towards the lightweight former options, for now at least, but with these notes:
The text was updated successfully, but these errors were encountered: