Skip to content
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

parse(Float64,::String) doesn't respect rounding mode #13481

Closed
dpsanders opened this issue Oct 7, 2015 · 15 comments
Closed

parse(Float64,::String) doesn't respect rounding mode #13481

dpsanders opened this issue Oct 7, 2015 · 15 comments
Labels
upstream The issue is with an upstream dependency, e.g. LLVM

Comments

@dpsanders
Copy link
Contributor

In

https://travis-ci.org/dpsanders/ValidatedNumerics.jl/builds/84036519

the tests for the ValidatedNumerics.jl package, which include lots of rounding mode changes,
run correctly on Mac OS, but give some incorrect results on Linux.

Could this be due to extended precision mode? How can this be turned off?
Or is there another explanation?

Cc @simonbyrne

@simonbyrne
Copy link
Contributor

I'm not really familiar with the package: can you provide some specific examples of the incorrect behaviour?

@dpsanders
Copy link
Contributor Author

I'll try and reduce to some minimal cases. cc @lbenet

@vtjnash
Copy link
Member

vtjnash commented Oct 7, 2015

Are you calling libm functions? I seem to recall that those may modify the rounding mode on some systems, or give incorrect answers if the rounding mode is changed.

@dpsanders
Copy link
Contributor Author

We should just be doing rounding mode changes like

julia> a = with_rounding(Float64, RoundDown) do
           parse(Float64, "0.1")
       end
0.09999999999999999

julia> 

julia> b = with_rounding(Float64, RoundUp) do
           parse(Float64, "0.1")
       end
0.1

@JeffreySarnoff
Copy link
Contributor

with your example using rc4 on Win7, a==b==0.1
Julia Version 0.4.0-rc4 Commit e9c9c92* (2015-10-04 03:14 UTC)
System: Windows (x86_64-w64-mingw32)
CPU: Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz WORD_SIZE: 64

with your example using rc2 on Linux (same box), a!=b, b==0.1, a=b-eps(b)
Julia Version 0.4.0-rc2 Commit fa52609* (2015-09-18 17:51 UTC)
System: Linux (x86_64-unknown-linux-gnu)
CPU: Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz WORD_SIZE: 64

@JeffreySarnoff
Copy link
Contributor

and using rc4 on same Linux also worked correctly

@simonbyrne
Copy link
Contributor

From what I understand, we use the system strtod for this, so I'm guessing this is a problem with glibc. They're actually pretty careful about this stuff, so if that's the problem it may be worth reporting upstream. What version are you using? (you can find out by running /lib/libc.so.6).

@lbenet
Copy link
Contributor

lbenet commented Oct 8, 2015

The expected results for the tests (which fail in travis!) correspond to your results in Linux; we get exactly the same in our Macs and also in linux with Julia Version 0.4.0-rc4+4, Commit 7048c40* (2015-10-07 00:33 UTC). The system is Linux (x86_64-suse-linux)
CPU: AMD Opteron(tm) Processor 6376.

As for Simon's question, on that linux machine we have:
GNU C Library (GNU libc) stable release version 2.17 (git c758a6861537).

Do you know this info for travis?

@JeffreySarnoff
Copy link
Contributor

GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.6) stable release version 2.19,
Copyright (C) 2014 Free Software Foundation, Inc.
Compiled by GNU CC version 4.8.2.
Compiled on a Linux 3.13.11 system on 2015-02-25.

@simonbyrne
Copy link
Contributor

This looks like it might have been fixed in glibc 2.17:
https://sourceware.org/bugzilla/show_bug.cgi?id=3479

From what I can tell, travis is running eglibc 2.15, so that would explain it. I don't know if there is any way to update it via apt (though I would suspect not, since it is so tightly linked to the OS).

At some point in future I think we should try to implement our own version, this would also fix our issues with MSVC (#6349).

@simonbyrne simonbyrne changed the title Rounding differences on Mac OS and linux -- due to extended precision? parse(Float64,::String) doesn't respect rounding mode Oct 8, 2015
@lbenet
Copy link
Contributor

lbenet commented Oct 8, 2015

This looks like it might have been fixed in glibc 2.17:
https://sourceware.org/bugzilla/show_bug.cgi?id=3479

From what I can tell, travis is running eglibc 2.15, so that would explain it. I don't know if there is any way to update it via apt (though I would suspect not, since it is so tightly linked to the OS).

@tkelman Is it possible to upgrade travis to incorporate some bug fixes in glibc?

@tkelman
Copy link
Contributor

tkelman commented Oct 8, 2015

They may have an opt-in way to use ubuntu 14.04 by now, not sure. If it is only available via a docker worker then we would have to replace all the apt-get steps in our travis setup.

@tkelman
Copy link
Contributor

tkelman commented Oct 9, 2015

If you're asking about a package, then try putting the following in your yml:

sudo: required
services:
  - docker

Actually reading http://blog.travis-ci.com/2015-08-19-using-docker-on-travis-ci/, it looks like we could maybe transition our main Linux Travis setup to caching things via docker.

lbenet pushed a commit to JuliaIntervals/ValidatedNumerics.jl that referenced this issue Oct 9, 2015
@lbenet
Copy link
Contributor

lbenet commented Oct 9, 2015

The problem is indeed related with our package (see JuliaIntervals/ValidatedNumerics.jl#56); while tests pass locally (in Linux and Mac), they fail in travis.

I followed your suggestion and finally the tests pass also in travis! Thanks a lot !!!

@JeffBezanson JeffBezanson added the upstream The issue is with an upstream dependency, e.g. LLVM label Oct 23, 2015
@dpsanders
Copy link
Contributor Author

These seems to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream The issue is with an upstream dependency, e.g. LLVM
Projects
None yet
Development

No branches or pull requests

7 participants