GithubHelp home page GithubHelp logo

coq-community / topology Goto Github PK

View Code? Open in Web Editor NEW
46.0 8.0 10.0 772 KB

General topology in Coq [maintainers=@amiloradovsky,@Columbus240,@stop-cran]

License: Other

Coq 99.94% Makefile 0.06%
coq coq-library topology

topology's People

Contributors

columbus240 avatar herbelin avatar letouzey avatar maximedenes avatar palmskog avatar ppedrot avatar silene avatar stop-cran avatar zimmi48 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

topology's Issues

Fix the compilation warnings

The newer coq versions give some compilation warnings about how some hints are defined. (fragile-hint-constr)

Look into that and either disable the warning or follow the recommendation of the warning (declare constants for the hints).

Can't compile with ZornsLemma

I have cloned topology and zorns-lemma, renamed the zorns-lemma directory to ZornsLemma and made it a sibling of topology.

The README states The library depends on my ZornsLemma contribution. The provided makefile expects compiled files to be present in ../ZornsLemma. This condition is met, but I still get the error:
Cannot find a physical path bound to logical path matching suffix <> and prefix ZornsLemma.

Recent warning fixes

Hi @stop-cran, long time no see.
Thanks for fixing the build warnings in your recent commits. (b46b4cd, 19de219, edbbddc)
A lot of the changes are only changing the line endings and back again, which clutters git blame.
Do you mind if I squash these three commits into a single one and force-push it to master?
This would keep the repo tidier.

Issue creating simple topological space

I want to create a very simple topological space on X={a,b,c} with the open sets T={{b},{b,c},{a,b},X,∅}, but I'm having great difficulty in doing so (code below). In particular, I'm stuck on this goal (see the location of admit in the code):

1 subgoal (ID 70)
  
  F : Family X
  HF : forall S : Ensemble X, In F S -> T S
  ============================
  T (FamilyUnion F)

also, is there a way to perform reflection on Ensembles to discharge the easy proof about being closed under finite intersections?

From Topology Require Import TopologicalSpaces.
Require Import Ensembles.

Section TopSpaceEx1.

Inductive X : Type := a | b | c.
From ZornsLemma Require Export EnsemblesImplicit.

Definition T (x : Ensemble X) : Prop := Same_set x (Singleton b)
                                  \/ Same_set x (Couple b c)
                                  \/ Same_set x (Couple a b)
                                  \/ Same_set x Full_set.
Ltac destruct_ensembles_in :=
 match goal with
   | [H : Ensembles.In _ _ |- _] => destruct H
 end.

Ltac destruct_ensembles :=
  split; red; intros;
    repeat destruct_ensembles_in.

Ltac inversion_ensembles_in :=
 match goal with
   | [H : Ensembles.In _ _ |- _] => inversion H; clear H
 end.

Ltac ensembles_inv :=
  let x := fresh "x" in
  let H := fresh "H" in
  split; red; intros x H; destruct x;
    repeat inversion_ensembles_in.

Lemma T_is_topology : TopologicalSpace.
Proof with auto with sets.
refine (Build_TopologicalSpace X T _ _ ltac:(firstorder)).
- intros F HF.
  admit.
- intros.
  destruct H as [? | [? | [? | ?]]];
  destruct H0 as [? | [? | [? | ?]]];
  apply Extensionality_Ensembles in H;
  apply Extensionality_Ensembles in H0; subst; unfold T.
  + left...
  + left; repeat destruct_ensembles; constructor.
  + left; repeat destruct_ensembles; constructor.
  + left; repeat destruct_ensembles; constructor.
  + left; repeat destruct_ensembles; constructor.
  + right; left; repeat destruct_ensembles; constructor.
  + left; ensembles_inv...
  + right; left; repeat destruct_ensembles; constructor.
  + left; repeat destruct_ensembles; constructor.
  + left; ensembles_inv...
  + right; right; left...
  + right; right; left; repeat destruct_ensembles; constructor.
  + left; red; repeat destruct_ensembles; constructor.
  + right; left; repeat destruct_ensembles; constructor.
  + right; right; left; repeat destruct_ensembles; constructor.
  + right; right; right...
Admitted.

End TopSpaceEx1.

SubspaceTopology Coercion

Is it possible (and easy to use) to create a coercion from Ensemble X to TopologicalSpace via @SubspaceTopology X, where X : TopologicalSpace?
This would be useful, because it allows some things to be stated more concisely (and is often done in mathematical practice). For example the notions "compact subset" or "connected subset" of a space would be automatically clear and wouldn't need to be defined separately.

The code

Coercion SubspaceTopology : Ensemble >-> TopologicalSpace.

Produces the warning SubspaceTopology does not respect the uniform inheritance condition [uniform-inheritance,typechecker] and Coq still says that SubspaceTopology is now a coercion.
But still, the following does not work:

From Topology Require Import SubspaceTopology Connectedness.
Coercion SubspaceTopology : Ensemble >-> TopologicalSpace.
Section S.
  Variable X : TopologicalSpace.
  Variable U : Ensemble X.
  Fail Variable V : Ensemble U.
  Fail Variable p : U.
  Fail Variable f : U -> X.
  Fail Goal connected U.
End Section S.

These basics would be necessary to simplify work with subspaces.

Long line & ordinals

I’d like to add some examples of (pathological) topological spaces to the library. For the long line I need the following:

  • Order Topology (already in the library)
  • Lexicographic order on the product of two orders (haven’t found it yet, if it’s already formalised)
  • The first uncountable ordinal ω_1.

I’m currently struggling with the definition of ω_1. Wikipedia gives Hartog numbers as slight hint. But my problem is not conceptual, in understanding the mathematics, but in the formalisation in Coq.
I’d like to use the Ordinal and well_founded definitions from Ordinals.v and WellOrders.v, but well_founded demands forall a b, a < b \/ a = b \/ a > b, while we can only prove forall a b : Ordinal, a < b \/ a == b \/ a > b. So the theorems of WellOrders.v remain unavailable for the Ordinal type. Interestingly, == isn’t extensional for Ordinal; for it is possible to prove ~ forall a b : Ordinal, a == b -> a = b.
I see three possible ways to continue:

  • Redefine the Ordinal type, so a == b -> a = b holds. That actually looks rather difficult, since we can’t easily take quotients. Maybe Induction-Induction would lead to a suitable definition, but currently that needs axioms, which isn’t very satisfying.
  • Redefine the well_founded definition (specifically total_strict_order) so it is only up-to-equivalence. I.e. use Setoids. But since the rest of the library avoids using Setoids, I don’t want to introduce them here.
  • Do the work I wanted to do with the Ordinal type, on the type of well_founded relations. Using a bundled structure (i.e. a Record WF_Type := { carrier : T; R : relation T; wf : well_founded R }.) might simplify the work, because always carrying T and R around is a bit annoying. It would be necessary to show that WF_Type is itself a well_founded type, then we could (probably) carry out the construction of ω_1. And the layered universes will probably make sure that no paradox arises.

We might want to add more theory about ordinals, like ordinal arithmetic. But hopefully with an ordinal type where a <= b -> a => b -> a = b.

P.S.: The proof that == is not extensional. We might want to add this to the library, as a reminder that == isn’t nice enough. The trick of the proof is to notice, that ord_sup isn’t injective with respect to ==. The term ord_sup (fun H:False => match H return Ordinal with end) corresponds to the ordinal zero.

Lemma ord_eq_not_extensional :
  ~ forall a b : Ordinal, a == b -> a = b.
Proof.
  intro.
  pose (a := (ord_sup (fun H:False => match H return Ordinal with end))).
  pose (b := (ord_sup (fun _:True=> (ord_sup (fun H:False => match H return Ordinal with end))))).
  assert (a == b).
  { unfold a, b.
    repeat constructor; intros; contradiction.
  }
  specialize (H a b H0).
  unfold a, b in *.
  inversion H.
  pose proof I.
  destruct H2.
  assumption.
Qed.

Give specific examples

Maybe it'd be useful to give some simple and practical examples to the defined topological constructions and proven theorems. E. g. a homeomorphism between a unit interval with identified ends and a unit circle.

Characterize RTop and its subspaces

There are multiple ways to characterize RTop and its subspaces (up to homeomorphism) based on order or metric properties. Such theorems could help transport topological properties.

IIRC the following statements are true:

  • Every order-complete, linear-order containing a countable and dense subset, is order-isomorphic to Rle on a closed interval.
  • Every non-empty, unbounded, linear order with the least-upper-bound property and a countable and dense subset is order-isomorphic to R.
  • Every unbounded, countable, dense linear order is isomorphic to Q.
  • Isomorphic orders induce homeomorphic topologies.
  • All open/closed intervals/rays in RTop are homeomorphic. By showing that each map x => a*x+b for a<>0 is an automorphism of RTop and
  • Homeomorphisms induce homeomorphisms on subspaces.

I'm sure there's some way to use the metric structure, but haven't yet looked into a precise statement. Metrically complete and separable are probably important again.

Small conjecture: an order topology is separable/second-countable iff there's a countable dense subset. A subset A of an ordered set X shall be called dense if for all x, y : X with x <= y there exists a : A such that x <= a <= y.

Add manifolds and smooth manifolds

An n-dimensional manifold M is a second countable Hausdorff space that is locally homeomorphic to Rⁿ . There seems to be several parts in the library already:

  • second_countable
  • Hausdorff
  • homeomorphic

The "locally homeomorphic" part requires that every point p ∈ M there is an open neighborhood U ⊂ M and a homeomorphism x : U -> U' for open U' ⊂ Rⁿ.

For smooth manifolds, the definition is a bit more involved and involves chart transformations and (Euclidean then topological) smoothness, which doesn't seem to be here yet.

Move set-theoretic lemmas to zorns-lemma

To develop topology we need many facts from set theory. For this the zorns-lemma library was initially developed. There are currently quite a few lemmas about sets (i.e. Ensembles) in the topology library, that could as well go into zorns-lemma.

I think it’d be "cleaner" if the facts & tactics about logic & set-theory that don’t depend on topological notions were moved to zorns-lemma. EnsembleTactic.v, InverseImageLemmas.v and the finite_indexed_union in SumTopology.v come to my mind.
If the current maintainers are ok with that, I’d copy the code mentioned above into zorns-lemma. I’d only remove the code here if the PR in zorns-lemma is accepted.

But this would only "fix" the current state. What if the topology library needs more set theory that hasn’t been developed yet in zorns-lemma? Every time we develop the new set-theoretic fact we would have to move it to zorns-lemma first, before we could commit the topologic fact depending on it...
I’m not yet sure about that. I think it would be a "nice" policy for this repo to have, but I’m not yet sure whether it is practical. What do you think?

Create coding style

Current code is somewhat hard to read. I'd suggest to create a coding style guide and amend all existing proofs to follow that style.

Below are my ideas about coding style to be discussed:

  • Use bullets in all proofs. For nested bullets of 5th order and deeper, consider extracting separate lemmas.
  • For goals generated by assert tactic use curly braces to logically separate from other goals. Possibly with other bullets inside the assertion goal if needed. E.g.:
    ...
    assert (forall a b:R, -b <= a -> a <= b -> Rabs a <= b).
  { intros.
    unfold Rabs.
    destruct Rcase_abs; lra. }
    intros.
    apply H.
    ...
  • Explicitly declare all terms, that are explicitly referenced later in proofs - current proofs are fragile because auto-generated names like H0, H1, H2, etc. tend to change all together in case of even minor proof amendments. E.g.:
...
destruct H.
apply H1. (* Fragile *)
...
destruct H as [? H1].
apply H1. (* Okay *)
...
  • Any other ideas?

Abstract away facts about "closed under finitary union/intersection"

Write a lemma in ZornsLemma of the form:

forall (X : Type) (fam : Family X),
  In fam Full_set /\ (forall U V, In fam U -> In fam V -> In fam (Intersection U V)) <->
  (forall (fin_fam : Family X), Included fin_fam fam -> Finite fin_fam -> In fam (FamilyIntersection fin_fam))

and one for union:

forall (X : Type) (fam : Family X),
  In fam Empty_set /\ (forall U V, In fam U -> In fam V -> In fam (Union U V)) <->
  (forall (fin_fam : Family X), Included fin_fam fam -> Finite fin_fam -> In fam (FamilyUnion fin_fam))

Applications for these lemmas arise/arose in the facts about filters and about open/closed sets. I already have these proofs, but I still need to rebase them.

I think, there’s some further generalization hiding in there... But that is probably not useful.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.