Should IntegrityCheck match restoreConformity? about tinfour HOT 3 CLOSED

Proposed fix starting at line 343 SemiVirtualIntegrityCheck:

    double h = geoOp.inCircle(a, b, c, d);

    if (h > 0) {
      if (e.isConstrained()) {
        // because the edge will not necessarily have had conformity
        // restored, we do not automatically treat the test as a failure here
        if (h > thresholds.getDelaunayThreshold()) {  // ADDED THIS TEST
          this.nDelaunayViolationsConstrained++;
          this.sumDelaunayViolationsConstrained += h;
          if (h > this.maxDelaunayViolationConstrained) {
            this.maxDelaunayViolationConstrained = h;
          }
        }
      } else {
        this.nDelaunayViolations++;
        this.sumDelaunayViolations += h;
        if (h > this.maxDelaunayViolation) {
          this.maxDelaunayViolation = h;
        }

        if (h > thresholds.getDelaunayThreshold()) {
          message = "InCircle failure h=" + h
            + ", starting at edge " + e
            + ": ("
            + a.getIndex()
            + ", " + b.getIndex()
            + ", " + c.getIndex()
            + ", " + d.getIndex() + ")";
          return false;

        }
      }
    }

from tinfour.

You make a good observation. The constrained-violation count was intended as a qualitative view of how often an inCircle() violation was suppressed due to a constrained edge. It would be more meaningful if it were changed to match the logic in the restore-conformity modules.

Coincidentally, I recently changed the wording in the IntegrityCheck printSummary() method from:

• Detected Delaunay violations within tolerance

to read

• Detected acceptable Delaunay violations within tolerance

I think this better conveys the fact that the algorithm tolerates very-small violations for efficiency purposes. Someday, when I have some spare time (as if that would ever happen), I want to try using Shewchuk's robust inCircle() implementation. Shewchuk's predicates are supposed to always give the correct answer regardless of numerical precision issues. It would be interesting to see how much performance overhead they require.

from tinfour.

Changes made as suggested and new code uploaded to git.

I am marking this issue as closed.

Thank you for your observation. Having a user with a fresh perspective on the code is a welcome resource.

from tinfour.