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(Analysis/Fourier/Derivative): Fréchet derivative of the Fourier transform #9663

Closed
wants to merge 9 commits into from

Conversation

AlexKontorovich
Copy link
Collaborator

We evaluate the Fréchet derivative of the Fourier transform, expressing it itself as a Fourier transform. The latter will allow one to iterate differentiation, eventually showing that the Fourier transform of a Schwartz function is also Schwartz.

Co-authored-by: Heather Macbeth 25316162+hrmacbeth@users.noreply.github.com


Open in Gitpod

@AlexKontorovich AlexKontorovich added awaiting-review The author would like community review of the PR t-analysis Analysis (normed *, calculus) labels Jan 11, 2024
Comment on lines +34 to +37
/-- The `integralFourier` of `f : E → F` is the specialization of `VectorFourier.fourierIntegral`
to the character `Real.fourierChar`, the `volume` form, and the ambient inner product on `E`. -/
abbrev integralFourier (f : E → F) :=
(VectorFourier.fourierIntegral (E := F)) Real.fourierChar (volume : Measure E) (innerₛₗ ℝ) f
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should probably go in Fourier.FourierTransform rather than here.

@loefflerd
Copy link
Collaborator

I had a draft for a mathlib3 PR doing much the same thing, but it got overtaken by the lean4 port and I never got around to forward-porting it. I'll dig it up and compare with what you wrote. (It's not unlikely that your work supersedes it entirely, but we may as well check.)

@loefflerd
Copy link
Collaborator

loefflerd commented Jan 12, 2024

Comparing with the Lean3 code I had lying around, there is indeed a difference.

You impose the condition [InnerProductSpace ℝ E], in order to interpret the Fourier transform of a function on E as a function on E. However, requiring an inner-product space structure (i.e. a symmetric positive-definite pairing) seems a bit limiting. For instance, in automorphic forms theory it's conventional to define the Fourier transform of functions on ℝ² by
$$\hat{\Phi}(x, y) = \int \Phi(u, v) e^{2\pi i (yu - xv)}\ \mathrm{d}u \mathrm{d}v,$$
i.e. with a symplectic bilinear form rather than a symmetric one; this has the advantage that $\hat{\hat{\Phi}} = \Phi$ (the annoying minus sign goes away).

I'd be in favour of a formulation where we don't privilege any choice of bilinear form, but instead takes as a parameter an arbitrary pairing L : V × W → ℝ, and sends functions on V to functions on W. This is what I coded up in Lean3: if v ↦ ‖v‖ * ‖f v‖ is integrable, then the derivative of the Fourier transform of f : V → E is the Fourier transform of v ↦ L(v, ⬝) • f v regarded as a function valued in Hom(W, E) [note my E is your F, and my V is your E].

Of course, one could potentially derive the more general bilinear-maps-space formulation from the inner-product-space formulation that you prove, by picking an arbitrary inner-product-space structure on V, and then pulling back along the unique map W → V determined by L. (There is an argument of the same type in mathlib already, in the proof of the Riemann-Lebesgue lemma.)

@loefflerd
Copy link
Collaborator

loefflerd commented Jan 12, 2024

So, I dug up my old code and ported it to mathlib4. See this branch: https://github.com/leanprover-community/mathlib4/tree/DL_fourier_deriv

(CI is reporting some errors on it at the moment, but that's just code-style glitches picked up by the linter; it does compile.) (edit: now fixed)

@loefflerd
Copy link
Collaborator

I've tried to merge together your approach and mine, by adding to my git branch a lemma which (up to relabelling the variables) is the main result from your branch, derived as a special case of the more general one for arbitrary pairings. I've also added the special case of scalar-valued functions (which is surprisingly hard to deduce from the general theory!)

How should we proceed from here? May I suggest we make a new PR with my branch, and credit all three of us as coauthors on it?

@sgouezel sgouezel added awaiting-author A reviewer has asked the author a question or requested changes and removed awaiting-review The author would like community review of the PR labels Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-author A reviewer has asked the author a question or requested changes t-analysis Analysis (normed *, calculus)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants