Show HN: Formally verified polygon intersection – Opus 4.8 oneshots, prev failed

github.com

79 points by permute 1 day ago

To my knowledge, this is the first formally verified implementation of an intersection algorithm for polygons.

The experience of working with AI agents on this project changed a lot with recent model releases, as I describe in the readme. Opus 4.8 is able to provide algorithm implementation with formal proof in one shot, whereas previous models required me to provide proof strategies in multiple steps.

Trust in the correctness comes entirely from the Lean checker and human review of a small specification, not from the LLM.

Also check out the web demo built around the verified core linked in the readme: https://schildep.github.io/verified-polygon-intersection/. It supports multipolygons including holes, self intersections, and overlapping edges.

simon84 2 hours ago

I'm not sure if the feature is intersection or the use of AI to write it...

Polygon intersection is a well known thing. Video games and geographic information systems (topology) do that for decades.

Tell me more, what should I look at ?

  • permute 1 hour ago

    Sure, what the program does is not interesting by itself, neither is that you can use AI to create programs to do polygon intersection.

    The main feature, that I hope is interesting in this submission, is that the program is formally verified and how I used formal verification together with AI to create it.

    Formal verification means that a mathematical proof is provided that the program satisfies a specification. And that proof is checked automatically by a deterministic system, the lean checker, which we can trust, in constrast to error prone LLMs.

    I gave the agent a formal specification m1.interior ∩ m2.interior = result.interior and it produced an implementation together with such a formal proof. With this approach we can treat much of the work of the agent as a black box, which we don't have to review to judge correctness.

    I think the project shows that as AI agents get more capable, an approach like this is starting to get practical for certain problems like polygon intersection for which there is a concise way to specify the problem.

prewett 1 day ago

This is a great use for AI! Calculating intersections is tedious and there are an surprising number of edge cases that are tedious to track down and fix.

  • permute 1 day ago

    Thanks! I am currently working on a follow up project for 3D polyhedrons for which the case handling really starts to get tedious. It's nice when AI can handle it without humans having to read the code and many unit tests to trust it.

CyLith 1 day ago

Does this use integer coordinates or floating point coordinates?

  • threatripper 1 day ago

    It uses exact rational coordinates, not floating-point coordinates in the verified core. See: https://github.com/schildep/verified-polygon-intersection/bl...

    • porcoda 1 day ago

      I am eager for a lean equivalent of flocq in rocq. When I did some lean verification of numerical algorithms I did the same thing with rationals or the reals from mathlib. The big gap between that and the actual code is the lack of a solid theory library to pull in that would give me IEEE floats that is at the same level of quality as Flocq. I’m eager for that to come along (unless it has and I just haven’t found it yet).

      • permute 1 day ago

        Thanks for the pointer, I will look into it.

        I think to do efficient formally verified geometry with floating point we would also need something like Shewchuk robust predicates. (I worked with them in the past to write robust software that is not formally verified. Did not read up, if there is a formally verified library for them.) Shewchuk robust predicates give certain consistency guarantees that are nice to have when implementing computational geometry with floating points and I think can be formalized.

    • permute 1 day ago

      Yes, the core supports exact rationals. This is easier to deal with in formal verification than floating point.

      I made the UI snap to a fixed precision, such that its easy to reproduce special cases with overlapping edges, coinciding vertices etc. that make up much of the complexity of the algorithm.

      • threatripper 1 day ago

        In a past life i tried to implement Delaunay triangulation in floating point for data that can come in a rotated square grid. Normal precision doesn't work in that case. I learned a lot about arbitrary precision numbers doing that. The question about floats here gave me flashbacks.

        • david-gpu 6 hours ago

          I can relate. Working in floating point hardware design gave me an irrational distaste for it. The horrors!

olaird25 1 day ago

Is the web demo compiled from the lean?

  • permute 1 day ago

    Yes, the webassembly is compiled from lean. The JS UI that calls the webassembly is not built from lean and not formally verified. So a human reviewer that does not trust the code, needs to review the formal spec and the UI code. But the geometry with rare special cases that we want to treat correctly happens in the verified core.

    • olaird25 1 day ago

      Nice. So is the js/lean interface using exact rationals?

deterministic 1 day ago

Impressive work. It's nice to see LEAN being used for real-world algorithms.

  • permute 1 day ago

    Thanks! Yes, I hope AI and Lean will enable formally verified practical software.