PI versus atan2(0,-1)

[J Naman]

This is not a Gawk bug per se, more of an end user bug if they are not
careful.
Several recent posts contain complaints about atan2(0,-1) (other than sign
flipping, which has been fixed in source code.) The most excellent Gawk
User Guide, 16.4.1.3 Errors Accumulate notes that "errors propagate" in
floating point calculations. and 16.4.2: "every floating-point operation
can suffer a new rounding error with catastrophic consequences"

Be aware that atan2(0,-1) is an ITERATIVE ALGORITHM with results subject to
PREC=n when using the MPFR & MP libraries. (GNU MP 6.1.2 GNU MPFR 4.0.2)
USE GAWK -M to invoke Gawk!
For example: The string constant pi to 50 digits=
"3.14159265358979323846264338327950288419716939937510";
Below, for PREC = 53, 113, 166 ('_' shows where results differ. It is
invisible.)
PREC=string constant
"3.141592653589793_23846264338327950_288419716939937510";
PREC= 53 atan2(0, -1) 3.141592653589793_11599796346854418_5162
PREC=113 atan2(0, -1) 3.141592653589793_23846264338327950_2797
PREC=166 atan2(0, -1) 3.141592653589793_23846264338327950_2884

A user said, "square-root-of-pi is frequently needed in any sort of
scientific computing"
PREC=113 sqrt(pi) 1.77245385090551_5992751519103139248377  using string
constant
PREC=113 sqrt(pi) 1.77245385090551_6027298167483341145140  sqrt(atan2(0,-1))

PREC=512 sqrt(pi) 1.77245385090551_5992751519103139248439  using string
constant
PREC=512 sqrt(pi) 1.77245385090551_6027298167483341145183  sqrt(atan2(0,-1))

For better precision, *why not hardcode* the
sqrt_pi="1.772453850905515992751519103139248439";
or run your GAWK programs with *-M -v PREC=512 *(or 1024 if you like)

also,FYI: EulersNumber="2.718281828459045235360287471352662497757247093";
Hope this helps someone ...