[Merged by Bors] - feat(Combinatorics/Graph): OrderBot instance for Graph

[Jun2M]

This PR adds an OrderBot instance for Graph α β, where the bottom element ⊥ is the empty graph (no vertices, no edges).

Co-authored-by: Peter Nelson apn.uni@gmail.com

---

[github-actions]

PR summary fa6418a815

Import changes for modified files

No significant changes to the import graph

Import changes for all files

Files	Import difference

---

Declarations diff

+ IsSubgraph.compatible
+ IsSubgraph.compatible'
+ banana_mono
+ bot_isClosedSubgraph
+ edgeSet_bot
+ eq_bot_or_vertexSet_nonempty
+ instance : Inhabited (Graph α β)
+ instance : OrderBot (Graph α β)
+ isClosedSubgraph_bot_iff
+ isInducedSubgraph_bot_iff
+ isSpanningSubgraph_bot_iff
+ le_noEdge_iff
+ ne_bot_iff
+ ne_bot_of_mem_vertexSet
+ noEdge_empty
+ noEdge_le_iff
+ not_disjoint_of_mem_mem
+ vertexSet_bot
+ vertexSet_eq_empty_iff
+ vertexSet_not_nonempty_iff
-- le

You can run this locally as follows

## summary with just the declaration names:
./scripts/pr_summary/declarations_diff.sh <optional_commit>

## more verbose report:
./scripts/pr_summary/declarations_diff.sh long <optional_commit>

The doc-module for scripts/pr_summary/declarations_diff.sh contains some details about this script.

---

No changes to technical debt.

You can run this locally as

./scripts/reporting/technical-debt-metrics.sh pr_summary

• The relative value is the weighted sum of the differences with weight given by the inverse of the current value of the statistic.
• The absolute value is the relative value divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).

[YaelDillies]

Sorry, I do not buy this still. For me, G = ⊥ is simpler and more useful than V(G) = ∅: it only involves equality, and can be substituted in. I would therefore suggest you build the API around G = ⊥ rather than V(G) = ∅. Right now, it looks like a confusing mix of both

[Jun2M]

I guess the question here is: should the negation of SNF(simp normal form) also be SNF?

In my view, answer is 'not necessarily'. "s.Nonempty is a great example: just because s = ∅ is SNF, you wouldn't argue s ≠ ∅ should be the SNF, not s.Nonempty, would you?

I agree that "G = ⊥ is simpler and more useful than V(G) = ∅". But I would also argue that V(G).Nonempty is more useful than G ≠ ⊥; In almost all cases I can think of, the next step from showing a graph is nonempty is to take a vertex from the said graph. In my mind, this situation is not so different from Set.Nonempty one.

In this perspective, there is no "mix", all equivalent forms of G = ⊥ are simplified to G = ⊥ and all equivalent forms of V(G).Nonempty are simplified to V(G).Nonempty. The fact that those two SNF are not negation of each other is not a problem.

[YaelDillies]

Let's ask someone else (@Bhavik Mehta ?) about the simp normal form question.

maintainer merge?

[github-actions]

🚀 Pull request has been placed on the maintainer queue by YaelDillies.

[b-mehta]

Thanks!

wrt the simp-normal-form question, I think the current set-up is sensible, we prefer = ∅ for the positive version and .Nonempty for the negative one.

[b-mehta]

bors merge

[mathlib-bors]

Pull request successfully merged into master.

Build succeeded:

• ci (staging) / Post-CI job
• ci (staging) / Build
• ci (staging) / Lint style
• ci (staging) / Post-Build Step