_round_mantissa rounds values just below 0.5 up to 1
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- machine-learning
Research direction
Start by reading _round_mantissa in the mx.elemwise_ops module and reproduce the issue with the Python example in the report. Add regression coverage for values just below 0.5 in both modes and verify the stated tie cases still round correctly; done when both modes return 0 for the reported input and the tie behavior is preserved.
Written by the indexing model from the issue text.
Description
Hi, _round_mantissa rounds a value just below 0.5 up to 1 in both the "even" and "nearest" modes. torch.floor(torch.abs(A) + 0.5) is evaluated in float32, and the addition already rounds up to 1.0 before the floor.
import torch
from mx.elemwise_ops import _round_mantissa
a = torch.tensor([float.fromhex("0x1.fffffep-2")]) # just below 0.5
for mode in ("even", "nearest"):
print(mode, _round_mantissa(a, 3, mode).tolist())
# Actual: [1.0] for both
# Expected: [0.0] for both
In an MX block this shows up as an element just below half the smallest magnitude rounding up. For example, in FP4 E2M1 at scale 2^0, the element 0x1.fffffep-3 becomes 0.5 instead of 0.
Reproduced on main at 7bc41952de394f5cc5e782baf132e7c7542eb4e4, with Python 3.12.13 and PyTorch 2.13.0 on CPU.
torch.round already rounds half to even without the intermediate addition, and the "nearest" branch can compare the fractional part instead:
elif round == "nearest":
- A = torch.sign(A) * torch.floor(torch.abs(A) + 0.5)
- elif round == "even":
absA = torch.abs(A)
- # find 0.5, 2.5, 4.5 ...
- maskA = ((absA - 0.5) % 2 == torch.zeros_like(A)).type(A.dtype)
- A = torch.sign(A) * (torch.floor(absA + 0.5) - maskA)
+ A = torch.sign(A) * (torch.floor(absA) + (absA - torch.floor(absA) >= 0.5).type(A.dtype))
+ elif round == "even":
+ A = torch.round(A)
With this change both modes give 0 here, ties still round correctly (0.5, 1.5, 2.5 and -2.5), and the output on 8,000 random blocks per element format is unchanged. Happy to send a PR with regression tests :)
- Dominant language
- Python
- Stars
- 365
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
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 microsoft/microxcaling
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
microsoft/microxcaling#48 ·
-
Finite FP16 MX blocks become NaNs on the default PyTorch pathPossibly taken @vera-rubin claimed this 8 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
microsoft/microxcaling#46 ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
microsoft/microxcaling#43 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
microsoft/microxcaling#42 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
microsoft/microxcaling#36 ·
All issues in microsoft/microxcaling
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
521xueweihan/HelloGitHub#4063 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Vanilla-OS/apx-gui#112 ·
-
Devstral and Voxtral: section 5 fails in us-east-1 with 400 "Model does not support audio modality"Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
aws-samples/sample-per-model-bedrock#409 ·
Maintainers usually reply within 1 day
-
DuckDB 2.0 breaks to_pyarrow_batchesPossibly taken @DG47 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
ibis-project/ibis#12196 ·
Maintainers usually reply within 1 day