Skip to content

refactor(Electromagnetism): replace fieldStrengthMatrix with index-evaluation components - #1614

Open
zhikaip wants to merge 5 commits into
masterfrom
fieldstrength_eval
Open

refactor(Electromagnetism): replace fieldStrengthMatrix with index-evaluation components#1614
zhikaip wants to merge 5 commits into
masterfrom
fieldstrength_eval

Conversation

@zhikaip

@zhikaip zhikaip commented Sep 3, 2026

Copy link
Copy Markdown
Collaborator

First of two PRs for the TODOs in Electromagnetism/Kinematics/FieldStrength.lean; the
follow-up fieldstrength_refactor removes the basis-representation lemmas.

Changes

  • Components of the field strength are accessed as toField {A.toFieldStrength x | [μ] [ν]}ᵀ
    everywhere. fieldStrengthMatrix and its API are removed, and every lemma stated with it is
    restated in eval form, with fieldStrengthMatrixtoFieldStrength_eval in the name.
  • Two new lemmas, toFieldStrength_eval_eq_tensor_basis_repr and
    toFieldStrength_tensor_basis_repr_eq_eval, bridge eval components and the coefficients in
    Tensor.basis, the tensor library's canonical basis. They replace the role of the
    fieldStrengthMatrix bridge lemmas: KineticTerm expands F_{μν}F^{μν} as a sum over
    Tensor.basis coefficients and needs to turn each coefficient into a component, and
    antisymmetry, additivity and homogeneity of toFieldStrength are derived from their
    component versions through the same bridge.
  • Tensors/Elab.lean: the bracket index syntax accepts a term instead of an ident, so
    concrete components such as [Sum.inl 0] [Sum.inr i] can be written. Existing uses are
    unaffected.
  • Four files gain attribute [-simp] Fin.succAbove_zero (MagneticField, Boosts, KineticTerm,
    Hamiltonian); each fails without it.
  • canonicalMomentum_eq is reproved via Lorentz.Vector.inner_eq_sum, and the two options
    in Vector/MinkowskiProduct.lean are dropped. With feat(Lorentz.Vector): mark Vector and CoVector implicit_reducible, add inner_eq_sum #1610 and fix(Tensors): rank the tensor action above the Tensorial action #1611 no
    respectTransparency option remains in the electromagnetism files.

Why

  • Index evaluation is the tensor library's own notation for components; fieldStrengthMatrix
    was a second representation of the same thing with a duplicate API.
  • Fin.succAbove_zero: plain simp rewrites Fin.succAbove 0 to Fin.succ inside the
    implicit colour index of evalT, after which no eval lemma matches. The tensor library
    disables it file-locally for the same reason; the attribute does not propagate.

replacements are mostly mechanical and AI seem to do a good job. I checked it to the best of my ability

zhikaip and others added 3 commits September 3, 2026 20:23
…aluation components

Resolves both TODOs in FieldStrength.lean. Components of the field strength
tensor are now accessed via `toField {A.toFieldStrength x | [μ] [ν]}ᵀ`
everywhere; `fieldStrengthMatrix` and the Finsupp-representation lemmas are
removed and replaced by `toFieldStrength_eval_*` lemmas.

To allow concrete indices such as `[Sum.inl 0]`, the tensor index-evaluation
bracket syntax in Relativity/Tensors/Elab.lean is widened from `ident` to
`term`.

Files using `simp` on evaluation terms gain
`attribute [-simp] Fin.succAbove_zero`, matching the guard already used in
the tensor library.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…wskiProduct options

`canonicalMomentum_eq` is reproved through `Lorentz.Vector.inner_eq_sum`
without `backward.isDefEq.respectTransparency` (possible now that
`Lorentz.Vector` is implicit-reducible). The two remaining options in
`Vector/MinkowskiProduct.lean` need both the implicit-reducible change and
the tensor-action priority fix, so they are removed here, on top of both.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…o files

IsExtrema and GaugeTransformation compile without it; Boosts, MagneticField,
KineticTerm and Hamiltonian still need it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@github-actions github-actions Bot added the large label Sep 3, 2026
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

  1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

  2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

  3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.

…eq_zero

The simpNF linter runs without the file-local `Fin.succAbove_zero` guard, under
which the eval left-hand side is not in simp normal form. The lemma is now
passed explicitly at the five `simp` sites that relied on it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@zhikaip

zhikaip commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator Author

Btw I think toField is extremely confusing with all the field strengths EM fields etc. flying around, I'm thinking of changing it to something like toScalar. I can do that in a follow up PR if you agree

@jstoobysmith

Copy link
Copy Markdown
Member

I think this would make sense. Sorry am at a conference, so haven't had time to look at this properly yet.

…ow-up PR

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

@jstoobysmith jstoobysmith left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This all looks good to me - have approved

@jstoobysmith jstoobysmith added the ready-to-merge This PR is approved and will be merged shortly label Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

large ready-to-merge This PR is approved and will be merged shortly

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants