Details
-
Task
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.6, 5.7, 5.8
-
None
Description
We have a qmath.h that, sensibly enough, does
#ifndef M_PI #define M_PI (3.14159265358979323846) #endif
Despite this, 302 other places in my Qt-dev source tree supply their own values for pi. There is some diversity of values. Let's start with the correctly-rounded ones:
- 3.14159
- 3.14159265 (enough for float - see below)
- 3.14159265358979
- 3.141592653589793 (enough for double - see below)
- 3.1415926535897932
- 3.141592653589793238
- 3.14159265358979323846 (same as M_PI in qmath.h)
- 3.1415926535897932384626433832795
- 3.14159265358979323846264338327950288
- 3.14159265358979323846264338327950288419717
- 3.14159265359
- 3.1415927
Then the truncated ones that aren't correct roundings (in each case, the last digit needs +1):
- 3.1415
- 3.141592
- 3.1415926
- 3.1415926535
- 3.141592653589
Finally, the values that look suspiciously like they were meant to be pi, but aren't (inserting a space after the last matching digit):
- 3.1415 2 (missing 9) In several parameters to sin(...)
- 3.14159 62 (last two digits swapped) In some JS benchmarks
- 3.14159265358979 23846 (missing 3) In an ECMA JS test
I am fairly sure the parameters to sin were meant to use pi; and I suspect changing the JS tests is out-of-scope as they look like imports (i.e. third-party).
Some of these are in JS (which can use Math.PI), including some in QML.
The ones in C++ code should surely use M_PI (and #include <qmath.h> to access it).
Some are in shaders, where we can't use either of those, but can at least be consistent about which literal value we use.
Attachments
Issue Links
- is covered by
-
QTBUG-108342 [q20] Back-port std::numbers::e, etc
-
- Open
-
Gerrit Reviews
For Gerrit Dashboard: QTBUG-58083 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
304830,3 | Deploy qmath.h's polymorphic values for constants | dev | qt/qtbase | Status: NEW | -1 | 0 |