Sorry for slow response.
Thanks @shanxi...@intel.com! Please rebase code to fix conflict.
Austin, Dwayne, Would you please take a look? Thanks!
const tests = [
These validation tests are only `cast`ing from `float32` here. But WPT WebNN Conformance tests of `cast` operator cover most supported type except tests of `uint64` type.
Is it ok to only casting from `float32` type for validation tests?
asu...@chromium.org, dwa...@microsoft.com Any suggestions? Thanks.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const tests = [
These validation tests are only `cast`ing from `float32` here. But WPT WebNN Conformance tests of `cast` operator cover most supported type except tests of `uint64` type.
Is it ok to only casting from `float32` type for validation tests?asu...@chromium.org, dwa...@microsoft.com Any suggestions? Thanks.
Are validation tests for `cast` necessary? According to https://www.w3.org/TR/webnn/#api-mlgraphbuilder-cast the only way `cast` can throw an exception is if the input is from another builder, which is tested above. The tests added only check that the output descriptor is correct. This is already tested by the conformance tests. Since these tests don't provide any additional coverage... do we need them at all?
If there are input type -> output type combinations which are not already tested in the conformance tests, we should remedy that by adding conformance tests which actually assert that the casted values (not just the output descriptor) are correct
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Austin SullivanThese validation tests are only `cast`ing from `float32` here. But WPT WebNN Conformance tests of `cast` operator cover most supported type except tests of `uint64` type.
Is it ok to only casting from `float32` type for validation tests?asu...@chromium.org, dwa...@microsoft.com Any suggestions? Thanks.
Are validation tests for `cast` necessary? According to https://www.w3.org/TR/webnn/#api-mlgraphbuilder-cast the only way `cast` can throw an exception is if the input is from another builder, which is tested above. The tests added only check that the output descriptor is correct. This is already tested by the conformance tests. Since these tests don't provide any additional coverage... do we need them at all?
If there are input type -> output type combinations which are not already tested in the conformance tests, we should remedy that by adding conformance tests which actually assert that the casted values (not just the output descriptor) are correct
Asutin, thank you for reviewing this CL. Yes, you're right. The conformance tests have already covered.
Shanxing, please abandon it. Thanks a lot for your contributions.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |