Conversation
|
Member
|
The |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Fixes #3794
The scan server loop command started out as basically
for (double value=start; value<=end; value += step).While this is quite a normal loop, with equivalent loops available in every programming language, there can be subtle rounding errors. A loop from 0 to 10.0 for example might end at 9.9999 instead of exactly 1.0, with details depending on the step size.
In PR #3305, commits 30964db and 0e2df3a tried to make it more predictable by avoiding rounding errors. Unfortunately, this disregarded the loop end points. A loop from
1.0to '2.0' in steps of2.0would now yield values1.0and3.0, with the latter clearly being beyond the loop end of2.0.A basic
for (double value=1.0; value<=2.0; value += 2.0)loop would only give a value of1.0and then end because the next potential value of1.0+2.0=3.0is beyond the loop end condition.I could argue that this original loop command behavior was good and didn't need to be "fixed" in the first place, but in keeping with the spirit of 0e2df3a to include the bounds, this update will will enforce the loop limits, resulting in a loop with values
1.0and2.0.Checklist