Prevent floating point shenanigans in loop termination (fixes #5012) #5013
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.
WRT #5012, this is from
splineoverlap.c
:The narrow problem is that the
for
loop isn't terminating becausediff
(around 1e-17) isn't large enough to change the value oft
(around 1).There's already that
false
-returningRealWithin(t1s[0],t1s[1],.01)
check, which may be intended to avoid this sort of problem. That isn't having an effect because the first guard succeeds -- the t2s and m2 values are all .000005 (or close enough to that thatWithin16RoundingErrors()
returnstrue
.This is all old GW code, most recently adjusted like this:
I'm confused about the guard succeeding only on the basis of t2s checks and then subsequently throwing out the t2s values (by setting them to -1), but it's not conclusively invalid to do so.
Still, we're fixing a hang here and I'm not sure it's worth digging into these larger questions to do it. So in this PR I'm just replacing the direct loop comparison with an int that goes from 1 to 16 and some calculations at the start of the loop.
Closes #5012