Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

completely regular spaces and locally compact implies uniform #1331

Merged
merged 14 commits into from
Oct 27, 2024

Conversation

zstone1
Copy link
Contributor

@zstone1 zstone1 commented Sep 30, 2024

We already have proofs about curry/uncurry which require locally compact and uniform. One one hand, these results are critical for homotopy theory. One the other hand they are badly phrased because locally compact implies uniform. That is what we prove here.

We follow the traditional proof, which is in 6 stages (2 of which were already done)

  • compact implies normal (we had compact implies regular, this is an easy extension)
  • normal implies completely regular (urysohn's lemma. already done as normal_separatorP + uniform_separatorP)
  • completely regular + hausdorff implies unformizable (via the construction of sup {(weak_topology f) | f : X -> R is continuous})
  • when X is locally compact + hausdorff, its one point compactification is compact + hausdorff
  • X embeds into its one point compactification (AKA X is in the weak topology from its OPC)
  • weak topologies respect uniformity (already done)

However, it's non-forgetful to just globally assign a Uniform to X. (And is legitimately dangerous. The nats with the discrete topology is hausdorff + locally compact, and does not have a unique uniformity).

Instead we do something slightly more general, and formalize the "continuous functions into the reals" construction by with a type completely_regular_uniformity .
So if you have a crsX : completely_regular_space X, then the type completely_regular_uniformity crsX is uniform and satisfies (completely_regular_uniformity crsX: topologicalType) = X. And coq is smart enough to exploit this equality, as seen in completely_regular_regular.

Then it is enough to prove locally_compact_completely_regular, which do via a local non-forgetful inheritance, so it's ok.

Checklist
  • added corresponding entries in CHANGELOG_UNRELEASED.md
  • added corresponding documentation in the headers

Reference: How to document

Reminder to reviewers

@zstone1 zstone1 added the enhancement ✨ This issue/PR is about adding new features enhancing the library label Oct 4, 2024
@zstone1 zstone1 force-pushed the locally_compact_uniform branch 2 times, most recently from ee04204 to 1057740 Compare October 10, 2024 19:41
@affeldt-aist
Copy link
Member

affeldt-aist commented Oct 14, 2024

the change to uniform_completely_regular was not documented in the changelog (unless I messed up with my changelog fix)

also, one_point_nbhs does not seem to be documented

@affeldt-aist
Copy link
Member

Should "one point" by written "one-point" in the documentation?

I was a bit suprised you chose to use "opc" as part of lemma
identifiers that are exposed to the user. Is it because it is a common abbreviation?
Otherwise, I would expect potential users to search lemmas using the substrings
such as "one", "point", or "compact", and potentially miss. Granted,
"one_point_compactification" is very long, maybe "one_point" only if "compactification" is immediately understood?
(not sure at all)

@zstone1
Copy link
Contributor Author

zstone1 commented Oct 14, 2024

I think one-point is better than one point. But I can't explain why.

And I definitely should not have exposed opc. Nobody would know what that means without context. The construction is not used all that often, so a long name is not a big deal. If we really wanted we could have both: the official lemma has a long name and also have a notation which aliases it. But I think that's overkill.

@zstone1 zstone1 force-pushed the locally_compact_uniform branch 2 times, most recently from d55bb11 to 108e886 Compare October 23, 2024 17:59
@affeldt-aist
Copy link
Member

affeldt-aist commented Oct 26, 2024

What about disabling the implicit parameter of normal_space and regular_space so that we are forces to write and see, say, normal_space T instead of just normal_space? This could make for better looking statements (e.g., completely_regular_regular) imo, it would correspond better to the documentation and the presentation of the various Ti might look more uniform.

@zstone1
Copy link
Contributor Author

zstone1 commented Oct 26, 2024

I think we did make that change, and just never went back and removed al the extra @s. We have

Arguments normal_space : clear implicits.
Arguments regular_space : clear implicits.

Removing the @s is an easy follow up PR I can do one this merges.

@affeldt-aist
Copy link
Member

affeldt-aist commented Oct 27, 2024

But instead of adding

Arguments normal_space : clear implicits.
Arguments regular_space : clear implicits.

you could also define normal_space and regular_space outside of the
set_separations section:

Definition normal_space (T : topologicalType) :=
  forall A : set T, closed A ->
    filter_from (set_nbhs A) closure `=>` set_nbhs A.

Definition regular_space (T : topologicalType) :=
  forall a : T, filter_from (nbhs a) closure --> a.

to get the desired effect (then a user grepping the definitions will always found them fully applied as advertised in the header).

@zstone1 zstone1 merged commit 6774a9d into math-comp:master Oct 27, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ This issue/PR is about adding new features enhancing the library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants