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
Gerrit Reviews
For Gerrit Dashboard: QTBUG-58083 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
197148,1 | Be (somewhat more) consistent about the value of pi | dev | qt/qtgraphicaleffects | Status: NEW | 0 | 0 |
304830,3 | Deploy qmath.h's polymorphic values for constants | dev | qt/qtbase | Status: NEW | -1 | 0 |