New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loss of accuracy of BigFloat on Win10-64bit plattform #22758

Closed
egarten opened this Issue Jul 11, 2017 · 16 comments

Comments

Projects
None yet
8 participants
@egarten

egarten commented Jul 11, 2017

I found an issue regarding BigFloats using julia0.6.0 on a Win10 system. This error does not appear on linux or macOS systems:

# Set precision to 7 million bits, so I expect about 2 million valid digits
setprecision(7000000)
# Get value of pi with high precision
bigpi=BigFloat(pi)
# Calculate difference of sin(pi/2)-1. Should be zero in exact arithmetic
sin(bigpi/BigFloat(2))-1
# Calualate difference of sin(pi/6)-1/2. Should be zero in exact arithmetic
sin(bigpi/BigFloat(6))-1/BigFloat(2)

For the first difference I get the value of zero. That means the result of sin(pi/2) is valid up to 2 million digits.

For the seconds difference I get an value of about 4.76993...e-306923. That means sin(pi/6) is only calculated up to about 300,000 digits and not 2 million digits.

Some more details have already been discussed:
https://discourse.julialang.org/t/accuracy-of-bigfloat-calculating-sin-with-high-accuracy/4604

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Jul 11, 2017

Anyone want to try it on 32-bit linux? Would be good to know if it's a Clong issue.

FWIW, there are some accuracy bounds of the implementation in http://www.mpfr.org/algorithms.pdf

@stevengj

This comment has been minimized.

Member

stevengj commented Jul 12, 2017

Note that the problem seems to be specifically in the sin function. If I do big(pi)/6 in this precision on MacOS (where sin is accurate), the last few digits are 399664339975e-01. On Win64, I get exactly the same answer, so it is computing π/6 correctly.

@vtjnash

This comment has been minimized.

Member

vtjnash commented Jul 12, 2017

For any library which uses libm where we care about numeric accuracy, we should be statically linking a copy of libopenlibm on platforms where the system libm is not accurate. We usually do this on Windows (since the old win32 crt math library was not very accurate) for many libraries. Do we know if MPFR is using libm functions though?

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Jul 12, 2017

I wouldn't think so.

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Jul 17, 2017

I see the same issue on a 32-bit linux VM.

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Jul 17, 2017

Okay, this is an issue with MPFR. The code here on 32-bit linux gives:

Diff is 4.7699306332221186288894962846258624262005363580770e-306923

@tkelman tkelman added the upstream label Jul 17, 2017

@stevengj

This comment has been minimized.

Member

stevengj commented Jul 17, 2017

@simonbyrne, thanks for looking into this. Can you send a bug report to mpfr@inria.fr as described here?

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Jul 17, 2017

Will do.

@simonbyrne

This comment has been minimized.

@tkelman

This comment has been minimized.

Contributor

tkelman commented Jul 18, 2017

looks like there's a patch already that we could try applying?

@stevengj

This comment has been minimized.

Member

stevengj commented Jul 18, 2017

Great, looks like they have a fix for MPFR 3.1. We could apply a patch before then if need be.

simonbyrne added a commit that referenced this issue Jul 18, 2017

tkelman added a commit that referenced this issue Jul 19, 2017

MPFR patch to fix sin on 32-bit long. (#22857)
* MPFR patch to fix sin on 32-bit long.

Fixes #22758.

* add flag and test for patch

* add test number

* use get_version as a function

jeffwong added a commit to jeffwong/julia that referenced this issue Jul 24, 2017

MPFR patch to fix sin on 32-bit long. (JuliaLang#22857)
* MPFR patch to fix sin on 32-bit long.

Fixes JuliaLang#22758.

* add flag and test for patch

* add test number

* use get_version as a function
@stevengj

This comment has been minimized.

Member

stevengj commented Sep 7, 2017

MPFR 3.1.5 includes the fix, so once we upgrade then we can delete our patch.

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Dec 5, 2017

I just tried this on 0.6.1, which is supposed to have the fix in, but still see the issue.

@simonbyrne simonbyrne reopened this Dec 5, 2017

@simonbyrne

This comment has been minimized.

Contributor

simonbyrne commented Dec 5, 2017

Ah, it was fixed in the 3.1.6 release, not 3.1.5 (which was released over a year ago). The link @stevengj pointed to are the bugs since the 3.1.5 release.

@simonbyrne simonbyrne closed this Dec 5, 2017

@StefanKarpinski

This comment has been minimized.

Member

StefanKarpinski commented Dec 5, 2017

Should we have a Julia-side regression test for this? Defense in depth and all that.

@KristofferC

This comment has been minimized.

Contributor

KristofferC commented Dec 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment