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

[Merged by Bors] - feat(analysis/normed_space/enorm): define extended norm #2897

Closed
wants to merge 4 commits into from

Conversation

urkud
Copy link
Member

@urkud urkud commented Jun 1, 2020

No description provided.

@urkud urkud added the awaiting-review The author would like community review of the PR label Jun 1, 2020
@sgouezel
Copy link
Collaborator

sgouezel commented Jun 2, 2020

I have a design question here. When one does analysis with, say, L^p functions, then one wants to work with functions (to be able to speak of the value of a function at a point), and not equivalence classes of functions, most of the time, and only switch to equivalence classes when applying some results of functional analysis. On the other hand, with your definition of enorm, where you require that only the zero function can have zero enorm, you can only put it on equivalence classes of functions.

Think for instance of the case where you speak of continuous functions on [0,1], and you want to say that the L^1 norm of your function is bounded by the C^0 norm. Since the C^0 norm works on genuine functions, not on equivalence classes, then the statement will become awkward to state and to use.

So, I am wondering if in the definition of enorm you should not also allow the enorm to vanish on more vectors than just 0. And then to e : enorm you could associate its kernel (the vector with 0 norm), and put an emetric space structure on V / e.ker, and a metric space structure on e.finite_subspace / e.ker.

Both options have pros and cons, so I just want to be sure that you have considered both of them before opting for one. (Avoiding quotients as you do is probably a good idea, in fact). It would be worth mentioning this in the docstring, too.

src/analysis/normed_space/enorm.lean Outdated Show resolved Hide resolved
src/analysis/normed_space/enorm.lean Outdated Show resolved Hide resolved
@urkud
Copy link
Member Author

urkud commented Jun 2, 2020

Both options have pros and cons, so I just want to be sure that you have considered both of them before opting for one.

No, I missed this point.

(Avoiding quotients as you do is probably a good idea, in fact).

Another approach: define eseminorm, then eseminorm.to_enorm (on the quotient space`). What do you think about this?

@sgouezel
Copy link
Collaborator

sgouezel commented Jun 2, 2020

I would say: for now, let's only define enorms as in your file. Maybe this will be sufficient, together with a coercion from functions to almost everywhere defined functions, and otherwise we will see what we need when we need it.

* use `𝕜` instead of `k`;
* add `semilattice_sup_top` instance;
* make `classical.prop_dec` a high priority instance;
* more docs
src/analysis/normed_space/enorm.lean Outdated Show resolved Hide resolved
src/analysis/normed_space/enorm.lean Outdated Show resolved Hide resolved
@sgouezel
Copy link
Collaborator

sgouezel commented Jun 3, 2020

bors r+

@github-actions github-actions bot 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-review The author would like community review of the PR labels Jun 3, 2020
bors bot pushed a commit that referenced this pull request Jun 3, 2020
Co-authored-by: sgouezel <sebastien.gouezel@univ-rennes1.fr>
@bors
Copy link

bors bot commented Jun 3, 2020

Pull request successfully merged into master.

Build succeeded:

@bors bors bot changed the title feat(analysis/normed_space/enorm): define extended norm [Merged by Bors] - feat(analysis/normed_space/enorm): define extended norm Jun 3, 2020
@bors bors bot closed this Jun 3, 2020
@bors bors bot deleted the enorm branch June 3, 2020 07:15
cipher1024 pushed a commit to cipher1024/mathlib that referenced this pull request Mar 15, 2022
…ommunity#2897)

Co-authored-by: sgouezel <sebastien.gouezel@univ-rennes1.fr>
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

2 participants