8000 ros/time.h fromSec implementation suffers from floating point inaccuracy, and stores invalid data · Issue #48 · ros/roscpp_core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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.

Sign up for GitHub

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

Jump to bottom

ros/time.h fromSec implementation suffers from floating point inaccuracy, and stores invalid data #48

Closed
televator opened this issue Jun 20, 2016 · 1 comment · Fixed by #49
Closed

ros/time.h fromSec implementation suffers from floating point inaccuracy, and stores invalid data #48

televator opened this issue Jun 20, 2016 · 1 comment · Fixed by #49
Labels
bug

Comments

@televator
Copy link

In some corner cases, floating point inaccuracy can lead to invalid data where nsec is calculated to be outside [0;1e9-1].
To illustrate the problem think of the following

#include <cmath>
#include <boost/math/special_functions/round.hpp>
int main()
{
        double someint = 1031.0; // some integer
        double t = std::nextafter(someint, 0); // someint - epsilon
        std::cout << next << std::endl;    // prints 1031.000000
        // ros implementation of fromSec
        uint32_t sec = (uint32_t)floor(t);
        uint32_t nsec = (uint32_t)boost::math::round((t-sec) * 1e9);
        std::cout << "sec"  << sec  << std::endl;   // prints 1030 (!)
        std::cout << "nsec"<< nsec << std::endl;  // prints 1000000000 (!)
}

(compile with c++11)
Correct behavior would be sec: 1031 nsec: 0, of course.

I guess the rounding behavior is desired in general, so a remaining fix would be to catch this specific case. Alternatively, the order could be changed to multiply with 1e9 -> round -> split into secs/nsec.
The latter solution requires an appropriately long integer data type for the temporary.
@dirk-thomas
Copy link
Member

Thank you for reporting this problem. Can you please contribute a pull request with your proposed fix checking if nsec is 1000000000 and then normalizes the time again (sec++, nsec=0). Thanks.

@televator televator mentioned this issue Jun 23, 2016
Merged
pgao pushed a commit to pgao/roscpp_core that referenced this issue Jul 2, 2016
fix the fix that was supposed to fix ros#48. also added a unit test.
487033d
pgao pushed a commit to pgao/roscpp_core that referenced this issue Jul 2, 2016
fix the fix that was supposed to fix ros#48. also added a unit test.
dffa31a
@pgao pgao mentioned this issue Jul 2, 2016
Merged
dirk-thomas pushed a commit that referenced this issue Jul 5, 2016
@pgao @dirk-thomas
fix the fix that was supposed to fix #48. also added a unit test. (#50)
78ebbe2 
fix the fix that was supposed to fix #48, also added a unit test (#50)
dirk-thomas pushed a commit that referenced this issue Feb 28, 2017
@pgao @dirk-thomas
fix the fix that was supposed to fix #48. also added a unit test. (#50)
d6bf610 
fix the fix that was supposed to fix #48, also added a unit test (#50)
@BrutusTT BrutusTT mentioned this issue Mar 20, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix rounding errors leading to invalid stored data in ros::TimeBase televator/roscpp_core
2 participants
@televator @dirk-thomas
0