The base and exponent of pow() should be allowed to have different data types
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Domain
- api, machine-learning
Research direction
This is a spec design question, not a code change: the issue asks whether pow() should get its own tensor data-type limits, separate from the same-type element-wise binary contract. Start with the ONNX Pow-15, TFLite tfl.pow and CoreML elementwise_binary.pow links to compare allowed base and exponent types. Done means the maintainers settle the open questions on exponent types and output type, then the spec text is updated to match.
Written by the indexing model from the issue text.
Description
Summary
pow() currently inherits the element-wise binary contract that requires both inputs to share the same data type. Unlike add/sub/mul — where both operands are the same kind of quantity — a power's base and exponent are conceptually distinct and are commonly different types (e.g. an integer or float32 exponent applied to a float16/int base). The same-type requirement forces redundant casts and rejects valid models.
Current behavior
We are currently encountering the following situation with the model (pow(int64_base, float32_exponent) is rejected at
graph-build time):
Backends status
- ONNX
Pow-15constrains X (and output) and Y with independent type sets — they need not match. Output type follows X (the base), consistent with WebNN's "output = a's type". - TFLite
tfl.powand CoreML MILelementwise_binary.powlikewise take base/exponent as separate operands.
Proposal and questions
- Give
pow()its own tensor limits- Should the
b(exponent) be restricted to a small set (e.g.float32+uint32, TFLite only support tensor of 32-bit float or 32-bit signless integer values), or allowed broadly？ - Should we accept the output based on the input
a(with integer truncation)?
- Should the
- Give
pow()its own data-type validation
- Dominant language
- Bikeshed
- Stars
- 566
- Forks
- 72
- Avg merge
- 6d 5h
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from webmachinelearning/webnn
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
webmachinelearning/webnn#967 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
webmachinelearning/webnn#966 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
webmachinelearning/webnn#965 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
webmachinelearning/webnn#964 · 1 comment · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
webmachinelearning/webnn#963 · 2 comments · 1 reaction ·
All issues in webmachinelearning/webnn
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Issue: ready for confirmation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Optimize consumer version heatmap aggregation to avoid repeated scansPossibly taken @praykaria31 claimed this today. Opentype/enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Apicurio/apicurio-registry#10662 · 1 comment ·
Maintainers usually reply within 1 day
-
[Bug]: Auto-uploaded local files get names containing the local path (extension taken from the whole path)Possibly taken @r2jaff claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
ComposioHQ/composio#5052 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day