Skip to content

feat(PhyslibAlpha): maximal current state of the open tight binding chain - #1716

Merged
jstoobysmith merged 1 commit into
leanprover-community:masterfrom
naype888-cloud:feat-physlibalpha-tight-binding-max-current-state-v2
Oct 2, 2026
Merged

jstoobysmith merged 1 commit into
leanprover-community:masterfrom
naype888-cloud:feat-physlibalpha-tight-binding-max-current-state-v2

Conversation

@naype888-cloud

@naype888-cloud naype888-cloud commented Oct 2, 2026 •

Copy link
Copy Markdown
Contributor

hello guys joseph, timeroot, here again with a short one. what this PR exactly does?
it adds "TightBindingChain/MaxCurrentState.lean" (300 lines), it comes directly from #1708 (current eigenstates) and #1709 (uncertainty on T.HilbertSpace). the longest standing wave, k = 1, is the one with the biggest current, so here we normalize it and compute its expectations. only 4 notes:

1.- "currentEigenvalue_le_one": for t ≥ 0, k = 1 carries the largest current 2 a t cos(pi/(N+1)) among all the current eigenstates.
2.- "maxCurrentState", "norm_maxCurrentState": the k = 1 eigenstate normalized, norm exactly 1.
3.- "expectation_openHamiltonian_maxCurrentState", "expectation_position_maxCurrentState": (H) = E0, the centre of the band, and (X) = a (N-1)/2, the centre of the chain.
4.- "expectation_bracket_maxCurrentState", "robertson_schrodinger_maxCurrentState": ((H, X)) = -a t cos(pi/(N+1)) and the energy-position uncertainty relation on this state.

why? this is the state where the next PR (#1718) checks when the uncertainty relation becomes an equality.

tks a lot guys, im here waiting for the review and ready for any changes¡

…hain

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added the medium label Oct 2, 2026
@github-actions

github-actions Bot commented Oct 2, 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.

@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.

Approved - will merge shortly.

@jstoobysmith jstoobysmith added the ready-to-merge This PR is approved and will be merged shortly label Oct 2, 2026
@jstoobysmith
jstoobysmith added this pull request to the merge queue Oct 2, 2026
Merged via the queue into leanprover-community:master with commit 77b61f4 Oct 2, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

medium 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