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

feat(data/real/ereal): add ereal := [-oo,oo] #1703

Merged
merged 20 commits into from
Jan 25, 2020
Merged

feat(data/real/ereal): add ereal := [-oo,oo] #1703

merged 20 commits into from
Jan 25, 2020

Conversation

kbuzzard
Copy link
Member

TO CONTRIBUTORS:

Make sure you have:

  • reviewed and applied the coding style: coding, naming
  • reviewed and applied the documentation requirements
  • for tactics:
  • make sure definitions and lemmas are put in the right files
  • make sure definitions and lemmas are not redundant

If this PR is related to a discussion on Zulip, please include a link in the discussion.

For reviewers: code review check list

src/data/real/ereal.lean Outdated Show resolved Hide resolved
/-- A set of ereals has a Sup in ereal -/
theorem Sup_exists (X : set ereal) : has_Sup X :=
let Xoc : set (with_top ℝ) := λ x, X (↑x : with_bot _) in
dite (Xoc = ∅) (λ h, ⟨⊥, ⟨
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to use dite instead of its sugared version?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I needed a dependent if/then/else. What's the sugared way to do this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if h : Xoc = ∅ then _ else _

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in ac2ac59

src/data/real/ereal.lean Outdated Show resolved Hide resolved
@fpvandoorn
Copy link
Member

I did some cleanup in this PR. I hope that is fine.

@fpvandoorn fpvandoorn added the awaiting-author A reviewer has asked the author a question or requested changes label Nov 19, 2019
@kbuzzard
Copy link
Member Author

@kbuzzard
Copy link
Member Author

OK so the situation with this PR was that I needed ereal and the proof that it was a complete lattice, which was initially a more substantial piece of work. It was then suggested that I prove a more general theorem about adding top and bot to a conditionally complete lattice gives a complete lattice, and this all happened in #1725 . The result is that this PR is essentially basic facts about unary neg on ereal and nothing else. I don't really know if this is worthy for mathlib any more so if people just want to close it then this is fine, but if people think it's better as a stub then here it is. I am unlikely to go any further with this now; in my opinion things like addition are unnatural on ereal, we have addition on the reals anyway.


/-- ereal : The type $$[-\infty,+\infty]$$ or `[-∞, ∞]` -/
@[derive [linear_order, lattice.order_bot, lattice.order_top,
lattice.has_Sup, lattice.complete_lattice]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you derive has_Sup but not has_Inf?


-/

/-- ereal : The type $$[-\infty,+\infty]$$ or `[-∞, ∞]` -/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/-- ereal : The type $$[-\infty,+\infty]$$ or `[-∞, ∞]` -/
/-- ereal : The type `[-∞, ∞]` -/

@@ -26,6 +26,8 @@ class has_bot (α : Type u) := (bot : α)
notation `⊤` := has_top.top _
notation `⊥` := has_bot.bot _

attribute [pattern] lattice.has_bot.bot lattice.has_top.top
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It allows us to write and in the equation compiler, like this:

protected def neg : ereal → ereal
| ⊥       := ⊤
| ⊤       := ⊥
| (x : ℝ) := (-x : ℝ)

@sgouezel
Copy link
Collaborator

Don't with_top and with_bot constructions automatically extend addition and/or multiplication? If so, this means that your ereal already has some of these operations. It might be worth checking which operations are already defined, and mentioning it in the docstring. Other than this, having a stub like this one is definitely better than nothing.

@kbuzzard
Copy link
Member Author

kbuzzard commented Jan 3, 2020

(sorry, I will get to this at some point, I have a bunch of references to write before I leave for the US this weekend)

@kbuzzard
Copy link
Member Author

kbuzzard commented Jan 5, 2020

OK so so the answer to the with_top and with_bot question of @sgouezel is that ereal will inherit an addition if I @derive it on line 38, but because apply_instance does not unfold ereal the addition is not inherited otherwise. So there are two choices: either I leave things as they are, or I derive addition and then prove some simp and refl lemmas about it (n.b. bot + top = top, for what it's worth).

I guess that given that a mathematician would say that addition is partially defined on ereal, I should derive addition and prove the simp lemmas, right? The only possible issue I can see with this is if someone wants bot + top to be bot for some reason (which it probably would have been if I'd defined ereal to be with_bot (with_top real).

Going further with this, I could define sub and mul and div (and even pow??), just giving them junk values at places where I would consider them undefined. What should I do here? Sorry this has all taken so long; I will finish up this PR within the next day or two now Christmas is over.

@sgouezel
Copy link
Collaborator

sgouezel commented Jan 8, 2020

I would say that you can just derive addition, but don't bother proving its properties: if someone needs them, then he will come back to it. Maybe add a comment in the file docstring though?

@kbuzzard
Copy link
Member Author

OK I derived addition. I am still a bit conflicted by all this; I guess my instinct is to leave things as they are until someone actually needs some arithmetic on ereal. I only need inf and sup, and I have these now.

@sgouezel sgouezel added ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.) and removed awaiting-author A reviewer has asked the author a question or requested changes labels Jan 25, 2020
@mergify mergify bot merged commit d3e5621 into master Jan 25, 2020
@mergify mergify bot deleted the ereal branch January 25, 2020 23:46
anrddh pushed a commit to anrddh/mathlib that referenced this pull request May 15, 2020
…1703)

* feat(data/real/ereal): add `ereal` := [-oo,oo]

* some updates

* some cleanup in ereal

* move pattern attribute

* works

* more docstring

* don't understand why this file was broken

* more tidyup

* deducing complete lattice from type class inference

* another neg theorem

* adding some module doc

* tinkering

* deriving addition

Co-authored-by: Floris van Doorn <fpvdoorn@gmail.com>
Co-authored-by: Chris Hughes <33847686+ChrisHughes24@users.noreply.github.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
anrddh pushed a commit to anrddh/mathlib that referenced this pull request May 16, 2020
…1703)

* feat(data/real/ereal): add `ereal` := [-oo,oo]

* some updates

* some cleanup in ereal

* move pattern attribute

* works

* more docstring

* don't understand why this file was broken

* more tidyup

* deducing complete lattice from type class inference

* another neg theorem

* adding some module doc

* tinkering

* deriving addition

Co-authored-by: Floris van Doorn <fpvdoorn@gmail.com>
Co-authored-by: Chris Hughes <33847686+ChrisHughes24@users.noreply.github.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants