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

Lead to inaccurate comparison, using EPSILON to correct. #350

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@devnexen

devnexen commented Mar 31, 2016

No description provided.

@@ -437,7 +439,7 @@ void RateMeter::update(double amount, const struct timeval *now) {
interval = MAX(current_rate_history, diff);
else
interval = TIMEVAL_SUBTRACT(*now, start_tv) / 1000000.0;
assert(diff <= interval);
assert(diff <= interval + std::numeric_limits<double>::epsilon());

This comment has been minimized.

@ghost

ghost Jul 8, 2016

After investigation it seems like this is not an accurate method for comparaison between doubles less than 1.0, and it is possible to obtain interval == 0.0 so it may not be accurate enough for this comparaison. At https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/, the author explains how float(pi)+sin(float(pi)) is more accurate than float(pi) to pi. I would suggest to compare double(interval)+sin(double(interval)) to double(diff)+sin(double(diff))... but I didn't check if the results would be in fact more accurate. What do you think?

@ghost

ghost Jul 8, 2016

After investigation it seems like this is not an accurate method for comparaison between doubles less than 1.0, and it is possible to obtain interval == 0.0 so it may not be accurate enough for this comparaison. At https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/, the author explains how float(pi)+sin(float(pi)) is more accurate than float(pi) to pi. I would suggest to compare double(interval)+sin(double(interval)) to double(diff)+sin(double(diff))... but I didn't check if the results would be in fact more accurate. What do you think?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 16, 2016

Hello @devnexen, after some tests, it seems like your suggestion is the most accurate one among a few others. I will thus publish your commit soon by crediting it to you. Talk to you soon and thank you for the contribution!

ghost commented Jul 16, 2016

Hello @devnexen, after some tests, it seems like your suggestion is the most accurate one among a few others. I will thus publish your commit soon by crediting it to you. Talk to you soon and thank you for the contribution!

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Jul 19, 2016

@W0naN0w Would you mind publishing as a gist and linking here the test code you used to determine what methods were accurate for comparison here?

dmiller-nmap commented Jul 19, 2016

@W0naN0w Would you mind publishing as a gist and linking here the test code you used to determine what methods were accurate for comparison here?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 20, 2016

@dmiller-nmap Of course! Sorry for yesterday I had a rough day. Here is the test I used to come to this conclusion: Gist link. You can find the output of the tests at the same place: Gist output link.
I hope it's what you were looking for, because I don't really know how to make a clearer test.

ghost commented Jul 20, 2016

@dmiller-nmap Of course! Sorry for yesterday I had a rough day. Here is the test I used to come to this conclusion: Gist link. You can find the output of the tests at the same place: Gist output link.
I hope it's what you were looking for, because I don't really know how to make a clearer test.

@nmap-bot nmap-bot closed this in c104245 Oct 16, 2016

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