Repository navigation
Math.atan() behavior change #56796
Description
Activity
- addedv8 engineIssues and PRs related to the V8 dependency.Issues and PRs related to the V8 dependency.
on Jan 28, 2025 Hi, thanks for the report. From our side there's not much we can do as Math global is managed by V8. We may have to backport or revert something in our V8 folder.
cc @nodejs/v8
One interesting thing is
node -p process.versions.v8prints11.3.244.8-node.23on both node 20.18.0 and 20.18.1. So both seem to be using the same v8 version.This change in behavior is reproducing for me in the same way as #56762 (more specifically #56762 (comment), but now I'm not questioning #55056).
Should we also include #56737 ?I ran a bisect, It did not worked. But I found something, could it be a "build-server" issue (dependency)?
$ node -v v20.17.0 $ ./node -v v20.17.0 $ node -e 'console.log(Math.atan(2.859624123917431))' 1.2343920821908787 $ ./node -e 'console.log(Math.atan(2.859624123917431))' 1.234392082190879
Reacted by Jordan Harbandcould it be a "build-server" issue (dependency)?
I think this corresponds to the update from macOS 11 to macOS 13 in the release infra.
Reacted by Juan JoséI'm reasonably sure I encountered a similar bug in quickjs-ng, see quickjs-ng/quickjs#268 (comment).
V8 has its own implementation of atan in deps/v8/src/base/ieee754.cc, it doesn't use libm's. The fix in our case was to either make the doubles
volatile, or compile with-mno-fmato disable the fused multiply-adds that affected the precision of intermediate results.Reacted by Juan José, Tony Pujals and Anthony RoachI'm reasonably sure I encountered a similar bug in quickjs-ng, see quickjs-ng/quickjs#268 (comment).
FWIW, the QuickJS Date.UTC test failing for
node-testis how I noticed the problem I reported in #56762.Should we also include #56737 ?
How is that issue related?
How is that issue related?
My bad, I don't think they are related at all. It is just this idea of "wrong format, then ICU problem". Sorry, I'll try to be a bit more careful.
github-actions commented
on Apr 22, 2026 on Apr 22, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Apr 22, 2026 github-actions commented
on May 22, 2026 on May 22, 2026 – with GitHub ActionsContributorMore actionsThis issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Version
v20.18.1
Platform
Subsystem
Math
What steps will reproduce the bug?
Math.atan(2.859624123917431)
How often does it reproduce? Is there a required condition?
It happens all the time on Mac OS X.
What is the expected behavior? Why is that the expected behavior?
1.2343920821908787
This is what older versions of node.js returned, and what all versions of node.js on Linux x86 return.
What do you see instead?
1.234392082190879
Additional information
1.234392082190879is actually the more correct result and agrees with Python and Wolfram Alpha. But the concerning thing is that the result changed between v20.18.0 and v20.18.1 on Mac OS X arm64 only. On Linux x86 all versions return the less correct result of1.2343920821908787. It would be nice if node.js on all platforms returned the same value. The difference is small but it is causing some headaches in our unit tests between platforms and node versions.Here's is what Wolfram Alpha shows with more significant digits:
1.23439208219087881390254524370678138808146132211060418165008615225322232