You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calculated sines, cosines, etc. of all kind of values, including huge ones. I had a different goal, but in the process I discovered this bug, because I compared Go's math functions' outputs with FriCAS (it can calculate with, e.g., 15000 digits of precision, which provides an effectively accurate result).
What did you expect to see?
Normally, I would just brush aside the meaningless results given huge arguments, but it seems Go actually supports that, having looked at some commit histories, Github issues, and src/math/huge_test.go. In particular, see 98521a5@bmkessler and #6794.
Thus I would expect math.Sin and company to be accurate up to the last couple of bits of the mantissa (e.g., ULP error < 1000).
What did you see instead?
It seems the Payne-Hanek range reduction is not working properly as some inputs produce meaningless results given arguments above 10^31.
Some data for math.Sin, see attached file for more rangeReductionFailures.txt. Each line records a point where math.Sin is wrong in about 37 bits of the mantissa or more:
EDIT: added excerpt from the file for inputs around 2.6e+307
I am not an expert, but #31566 says package math is not using Payne-Hanek enough, while my issue is about Payne-Hanek (or the implementation) being wrong. https://go-review.googlesource.com/c/go/+/172838 likewise just expands the use of Payne-Hanek (by lowering the threshhold), while the fix for my issue would presumably belong to either func trigReduce or var mPi4. Thus these issues are actually complementary, or even opposite. EDIT: since this bug happens with the entire possible range of exponents, var mPi4 is probably correct and func trigReduce is probably wrong.
BTW, I uploaded the entire file with the diffs now, so the input values in it now go up to +Inf, approximately. And, BTW, the file does not list all the points for which this bug happens. And to repeat my self for clarity, it features results for math.Sin in every line.
Oops: turns out converting from the high precision floating point type to binary64 and back again fixes the Fricas results. In other words I did sin(HUGEFLOATVAL) instead of sin(HUGEFLOATVAL::DoubleFLoat::Float) in Fricas, where HUGEFLOATVAL was obtained from Go's fmt.Printf("%35.30e", ...), and this greatly affects results for huge arguments.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Dunno. Probably.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Calculated sines, cosines, etc. of all kind of values, including huge ones. I had a different goal, but in the process I discovered this bug, because I compared Go's math functions' outputs with FriCAS (it can calculate with, e.g., 15000 digits of precision, which provides an effectively accurate result).
What did you expect to see?
Normally, I would just brush aside the meaningless results given huge arguments, but it seems Go actually supports that, having looked at some commit histories, Github issues, and src/math/huge_test.go. In particular, see 98521a5 @bmkessler and #6794.
Thus I would expect math.Sin and company to be accurate up to the last couple of bits of the mantissa (e.g., ULP error < 1000).
What did you see instead?
It seems the Payne-Hanek range reduction is not working properly as some inputs produce meaningless results given arguments above 10^31.
Some data for math.Sin, see attached file for more rangeReductionFailures.txt. Each line records a point where math.Sin is wrong in about 37 bits of the mantissa or more:
EDIT: added excerpt from the file for inputs around 2.6e+307
The text was updated successfully, but these errors were encountered: