Merge branch 'master' into improve-maths-check-polygon

Author: mohitkumar188

.devcontainer/README.md

@@ -13,14 +13,15 @@ This is **Devcontainer** configuration to provide a consistent development envir
 
 ## Usage
 
-1. Install [**Docker** ](https://www.docker.com/get-started/) and [**Visual Studio Code**](https://code.visualstudio.com/)
+1. Install [**Docker**](https://www.docker.com/get-started/) and [**Visual Studio Code**](https://code.visualstudio.com/)
 2. Install the **Remote - Containers** extension in VS Code
 
     - Do `CTRL+P`, paste this command and press `Enter`
 
         ```shell
         ext install ms-vscode-remote.remote-containers
         ```
+
 3. Open this repository in VS Code
 4. When prompted, click **"Reopen in Container"**
 5. Wait for the environment to build and initialize

.github/dependabot.yml

@@ -6,3 +6,5 @@ updates:
     directory: "/"
     schedule:
       interval: "daily"
+    cooldown:
+      default-days: 7

.github/pull_request_template.md

@@ -1,21 +1,20 @@
-### Describe your change:
-
-
+### Describe your change
 
 * [ ] Add an algorithm?
 * [ ] Fix a bug or typo in an existing algorithm?
 * [ ] Add or change doctests? -- Note: Please avoid changing both code and tests in a single pull request.
 * [ ] Documentation change?
 
-### Checklist:
+### Checklist
+
 * [ ] I have read [CONTRIBUTING.md](https://github.com/TheAlgorithms/Python/blob/master/CONTRIBUTING.md).
 * [ ] This pull request is all my own work -- I have not plagiarized.
 * [ ] I know that pull requests will not be merged if they fail the automated tests.
-* [ ] This PR only changes one algorithm file.  To ease review, please open separate PRs for separate algorithms.
+* [ ] This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
 * [ ] All new Python files are placed inside an existing directory.
 * [ ] All filenames are in all lowercase characters with no spaces or dashes.
 * [ ] All functions and variable names follow Python naming conventions.
 * [ ] All function parameters and return values are annotated with Python [type hints](https://docs.python.org/3/library/typing.html).
 * [ ] All functions have [doctests](https://docs.python.org/3/library/doctest.html) that pass the automated testing.
 * [ ] All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
-* [ ] If this pull request resolves one or more open issues then the description above includes the issue number(s) with a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue): "Fixes #ISSUE-NUMBER".
+* [ ] If this pull request resolves one or more open issues, then the description above includes the issue number(s) with a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue): "Fixes #ISSUE-NUMBER".

.github/skills/code-review/SKILL.md

@@ -33,6 +33,14 @@ suggest the fix — never just "rejected".
 - [ ] Descriptive variable and function names (no single letters where a word helps).
 - [ ] Code is formatted and lint-clean (`ruff`, `pre-commit`).
 
+> **Optional hint:** When a PR hand-writes a simple class that is mostly a
+> bundle of fields (a manual `__init__` plus `__repr__`/`__eq__`), it is worth
+> **suggesting** `from typing import NamedTuple` or
+> `from dataclasses import dataclass` where they would simplify the code. These
+> are underutilized tools that our contributors would benefit from using where
+> they make sense. Offer it as an optional improvement, not a blocker — do not
+> request changes solely because a class was written the longhand way.
+
 #### When a PR fails `ruff check`
 
 Don't just report the failure — try the mechanical fixes and recommend the one
@@ -61,7 +69,7 @@ flagged. Also, paste the concrete command you ran.
 
 Emit exactly these headings so reviews are comparable and easy to automate:
 
-```
+```text
 ### Is this an algorithm? — <yes/no + one-line why>
 ### Duplicate / prior-art check — <#NNNN | none found>
 ### Coding style — <pass | issues: …>

.github/skills/new-pull-request/SKILL.md

@@ -10,7 +10,7 @@ clear, kind, tested, type-hinted, mergeable contribution.
 Make sure that the local `master` branch is synced with `upstream/master` before
 creating a new pull request.
 
-Create a new clearly named branch for the pull request.  Pull request changes must
+Create a new clearly named branch for the pull request. Pull request changes must
 not be made or submitted on the `master` branch.
 
 Never hand-edit or revert the `uv.lock` file. If you add a legitimate
@@ -19,7 +19,13 @@ hand. A hand-modified `uv.lock` makes the `algorithms-keeper` bot close the pull
 request as invalid, and even a repo maintainer cannot undo that.
 
 Always check at least one Markdown checkbox in the pull request description (the "Describe your change" section), or the
-`algorithms-keeper` bot will close the pull request as invalid.  Any repo maintainer can undo this if you @mention them on the closed pull request.
+`algorithms-keeper` bot will close the pull request as invalid — and it does
+this *before* a human reads the PR, so a genuinely good change gets closed for a
+formatting reason. This applies to **every** pull request, including CI, docs,
+and tooling changes that are not algorithms: tick the boxes that genuinely apply
+so the body is never submitted with all boxes empty. Any repo maintainer can
+undo this if you @mention them on the closed pull request, but re-opening is
+often unreliable, so it is far better to get it right the first time.
 
 ### 1. Before contributing / Is this an algorithm?
 
@@ -41,6 +47,11 @@ Always check at least one Markdown checkbox in the pull request description (the
 - [ ] Public functions/classes have **type hints**.
 - [ ] Public functions have **doctests that actually pass**.
 - [ ] Descriptive variable and function names (no single letters where a word helps).
+- [ ] For a simple class that is mostly a bundle of fields, **consider**
+      `from typing import NamedTuple` or `from dataclasses import dataclass`
+      instead of a hand-written `__init__`/`__repr__`/`__eq__`. These are
+      underutilized tools that make simple classes shorter and clearer — use
+      them where they genuinely simplify the code, not everywhere.
 - [ ] Code is formatted and lint-clean (`ruff`, `pre-commit`).
 - [ ] `DIRECTORY.md` and `README.md` are **not hand-edited** — the
       `algorithms-keeper` bot regenerates them automatically after merge.
@@ -50,3 +61,15 @@ Always check at least one Markdown checkbox in the pull request description (the
 - [ ] At least one **Wikipedia (or equivalent) URL** documenting the algorithm.
 - [ ] Docstring explains what the function does and its parameters/returns.
 - [ ] No unnecessary third-party dependencies.
+
+## Before you click "Create pull request"
+
+This is the final gate. Do not open the pull request until every item here is true:
+
+- [ ] At least one Markdown checkbox in the PR description is checked. **Verify
+      this by re-reading the rendered body** — if every box is still `- [ ]`, the
+      `algorithms-keeper` bot will auto-close the PR before any human sees it.
+      Check the boxes that genuinely apply to this change; never submit an
+      all-empty checklist, even for a CI, docs, or tooling PR.
+- [ ] The branch is not `master`, and `master` is synced with `upstream/master`.
+- [ ] `uv.lock` was not hand-edited.

.github/skills/review-open-issue/SKILL.md

@@ -0,0 +1,110 @@
+# Skill: Review an open issue for TheAlgorithms/Python
+
+Triage an open issue — most often one carrying the `bug` label — **together with
+every pull request attached to it**, and produce a verdict a maintainer can act on
+without re-doing the work. The goal is a review that any triager (human or AI) can
+run the same way every time, and that ends in an explicit list of `Closes #NNNNN`
+lines the maintainer can paste into a merge commit.
+
+This repo exists to **teach visitors to fix bugs by doing**. So the default is to
+merge adequate existing contributor work, not to open a fresh PR that races them.
+Only open your own PR when no attached PR adequately solves the issue.
+
+## How to run this skill
+
+### 1. Reproduce before you trust the report
+
+- Check out current `master` and actually **run the failing case** from the issue.
+- If it reproduces, say so and paste the minimal reproducer (inputs → observed
+  output, e.g. `nan` + a `RuntimeWarning`).
+- If you **cannot** confirm it locally — an optional dependency isn't installed,
+  the failure needs an external service, the report is too vague — **say that
+  explicitly rather than guessing.** "Not reproducible in a vanilla checkout"
+  is a real, useful verdict.
+
+### 2. Classify the issue
+
+Sort each issue into one bucket and act accordingly:
+
+- **Confirmed bug with an adequate open PR** → recommend the specific PR to merge.
+- **Confirmed bug, no adequate PR** → open a new PR yourself (see step 5).
+- **Not a bug / working-as-intended** → recommend closing, and explain why (e.g.
+  binary search returning *an* index of a duplicate is correct, not a defect).
+- **Feature request mislabeled as a bug** → recommend dropping the `bug` label; do
+  **not** close it as a bug.
+- **Too vague / needs reporter info** → comment **on the issue itself** asking for
+  the one concrete thing missing (a file path, a traceback, a reproducer), and note
+  it should be closed if no answer arrives.
+- **Environment / optional-dependency, not an algorithm defect** → note it needs
+  someone with that environment; it is not fixable in a vanilla checkout.
+
+### 3. Examine every attached PR — pick one, name the duplicates
+
+For a bug with several open PRs:
+
+- **Verify each fix's doctest values numerically** against a trusted reference
+  (`scipy`, `numpy.linalg`, `geopy`, or a brute-force check over random inputs).
+  Don't take a doctest's word for it — confirm the number.
+- Prefer the **first-in PR with the smallest correct diff** that follows repo
+  convention (doctests over new test files, `raise` over `assert`, no unrelated
+  reindentation or churn of clean doctests into floating-point noise).
+- **Reject out-of-scope "fixes"** — e.g. swapping a real divide-by-zero for a
+  `1e-15` magic constant makes results implementation-defined. Fix the issue, not
+  more.
+- Identify the byte-for-byte **duplicates** so the maintainer can close them with
+  thanks in the same action.
+
+### 4. Emit the verdict — fixed output shape
+
+Post one comment that a maintainer can act on directly. For each issue give a
+one-line rationale and the exact autoclose line. Two formatting rules matter a lot
+to human maintainers scanning the thread:
+
+- **Start every line that references an issue or PR with a Markdown list marker
+  (`-` or `* `).** GitHub-flavored Markdown only autolinks `#NNNNN` inside a list,
+  and those autolinks are colored — **purple = merged, red = closed, green = open** —
+  so the maintainer can see merge/close progress at a glance. A bare `#14813` at the
+  start of a line does not autolink.
+- **Merging a PR that closes an issue also closes the issue's other open PRs**, so
+  fold the duplicates into one autoclose statement rather than listing the winner
+  alone:
+
+  ```text
+  * #14813 — 3x3 inverse returns the transpose → merge #14821
+    (Closes #14813, Closes #14840, Closes #15045)
+  ```
+
+Recommended shape:
+
+```text
+## Confirmed bugs with an adequate open PR — merge
+* #<issue> — <one-line what/why> → merge #<pr> (Closes #<issue>, Closes #<dupe>, …)
+
+## Not a bug / not merge-ready
+* #<issue> — <feature-request → relabel | needs cleanup | needs a human call>
+
+## Summary — lines to add
+* Closes #<issue> → #<pr>
+```
+
+### 5. When you must open your own PR
+
+If no attached PR is adequate, open one — but let the contributors keep the credit
+where their work was close. Use autoclose keywords in the **commit message body**
+so the merge closes the issue *and* the superseded PRs:
+
+```text
+Fixes #12233
+Fixes #12262
+Fixes #13635
+```
+
+Follow the [`new-pull-request`](../new-pull-request/SKILL.md) skill for the
+mechanics (synced `master`, named branch, checked description box, untouched
+`uv.lock`).
+
+## Tone
+
+Be specific and kind. Name the exact PR and the exact reason, credit the
+contributor by handle, and offer runners-up detailed feedback so they learn — the
+point of the repo is that people come back and fix the next one.

.github/workflows/build.yml

@@ -10,6 +10,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v7
+        with:
+          persist-credentials: false
       - uses: astral-sh/setup-uv@v7
         with:
           enable-cache: true
@@ -18,6 +20,12 @@ jobs:
         with:
           python-version-file: .python-version
           allow-prereleases: true
+      # keras needs hdf5 on pre-release Python.
+      - run: |
+          if [ "$(python -c 'import sys; print(sys.version_info.releaselevel)')" != "final" ]; then
+            sudo apt-get update -qq
+            sudo apt-get install --yes libhdf5-dev
+          fi
       - run: uv sync --group=test
       - name: Run tests
         # opencv-python is gated out on 3.14t (no cp314t wheel yet), so skip the

.github/workflows/devcontainer_ci.yml

@@ -15,6 +15,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v7
+        with:
+          persist-credentials: false
       - uses: devcontainers/ci@v0.3
         with:
           push: never

.github/workflows/directory_writer.yml

@@ -9,6 +9,7 @@ jobs:
       - uses: actions/checkout@v7
         with:
           fetch-depth: 0
+          persist-credentials: false
       - uses: actions/setup-python@v7
         with:
           python-version-file: .python-version

.github/workflows/hacktoberfest_prep.yml

@@ -0,0 +1,109 @@
+# Daily refresh of the Hacktoberfest 2026 open-PR cleanup tracker.
+# Ticks off any tracked pull request that has since been merged/closed, and
+# rewrites the "Automated statistics" section (open issue/PR counts + the top
+# three `awaiting reviews` directories). The job fails on purpose once
+# Hacktoberfest 2026 has begun (>= 2026-10-01), which is the signal to retire it.
+name: hacktoberfest_prep
+
+on:
+  push:
+    paths:
+      - ".github/workflows/hacktoberfest_prep.yml"
+      - "scripts/hacktoberfest_prep_update.py"
+  pull_request:
+    paths:
+      - ".github/workflows/hacktoberfest_prep.yml"
+      - "scripts/hacktoberfest_prep_update.py"
+  schedule:
+    - cron: "50 11 * * *" # 11:50 UTC every day
+  workflow_dispatch: # allow a manual run while testing
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  hacktoberfest-prep:
+    # No point running on forks — this pushes to the repo's own docs file.
+    if: github.repository == 'TheAlgorithms/Python'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          persist-credentials: false
+      - uses: actions/setup-python@v7
+        with:
+          python-version-file: .python-version
+          allow-prereleases: true
+      - name: Install dependencies
+        run: python -m pip install --upgrade "httpx2>=2.0.1"
+      - name: Update the tracker
+        id: update
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_REPOSITORY: ${{ github.repository }}
+        # Don't let the intentional post-Oct-1 failure stop the commit step;
+        # capture the exit code and re-raise it after pushing any changes.
+        run: |
+          set +e
+          python scripts/hacktoberfest_prep_update.py
+          echo "exit_code=$?" >> "$GITHUB_OUTPUT"
+      # Dry run on push / pull_request: show the diff the script produced but
+      # do NOT commit or push. This lets a PR prove the tracker still gathers
+      # its data and rewrites docs/hacktober_2026_prep.md correctly without
+      # leaving a permanent commit. Only the schedule/manual runs persist.
+      - name: Show changes (dry run)
+        if: github.event_name == 'push' || github.event_name == 'pull_request'
+        run: |
+          echo "Dry run (${{ github.event_name }}): showing git diff, not committing."
+          git --no-pager diff -- docs/hacktober_2026_prep.md
+          if git diff --quiet -- docs/hacktober_2026_prep.md; then
+            echo "No changes to docs/hacktober_2026_prep.md."
+          fi
+      # `master` is a protected branch: direct pushes are rejected with
+      # `GH006: Protected branch update failed ... Changes must be made through
+      # a pull request`. So instead of committing straight to master, persist
+      # the refreshed tracker on a single rolling branch and open — or, since
+      # re-pushing the branch updates the existing PR in place, leave open — one
+      # pull request. Uses the bundled `gh` CLI rather than a third-party
+      # action (see zizmor's "superfluous actions" audit).
+      - name: Open or update the tracker pull request
+        if: github.event_name != 'push' && github.event_name != 'pull_request'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          BRANCH: chore/hacktoberfest-2026-prep-refresh
+        run: |
+          set -euo pipefail
+          if git diff --quiet -- docs/hacktober_2026_prep.md; then
+            echo "No changes to docs/hacktober_2026_prep.md; nothing to persist."
+            exit 0
+          fi
+          git config --global user.name "$GITHUB_ACTOR"
+          git config --global user.email "$GITHUB_ACTOR@users.noreply.github.com"
+          # `actions/checkout` runs with `persist-credentials: false`, so git has
+          # no token to authenticate the push below (it fails with
+          # `fatal: could not read Username for 'https://github.com'`). Wire the
+          # bundled `gh` in as git's credential helper so `git push` reuses
+          # GH_TOKEN — no third-party action and no token baked into the remote URL.
+          gh auth setup-git
+          git switch -c "$BRANCH"
+          git add docs/hacktober_2026_prep.md
+          git commit -m "chore: refresh Hacktoberfest 2026 prep tracker"
+          # Force-push so the rolling branch always carries just the latest
+          # snapshot on top of master; this also updates any open PR in place.
+          git push --force origin "$BRANCH"
+          if [ -z "$(gh pr list --head "$BRANCH" --state open --json number --jq '.[].number')" ]; then
+            gh pr create \
+              --base master \
+              --head "$BRANCH" \
+              --title "chore: refresh Hacktoberfest 2026 prep tracker" \
+              --body "Automated daily refresh of the Hacktoberfest 2026 open-PR cleanup tracker (\`docs/hacktober_2026_prep.md\`): ticks off any tracked pull request that has since been merged/closed and rewrites the **Automated statistics** section.
+
+          This PR is updated in place by the \`hacktoberfest_prep\` workflow, so it always reflects the latest scheduled run. Merge it whenever you want to capture the current snapshot."
+          else
+            echo "Open tracker PR already exists; force-push updated it in place."
+          fi
+      - name: Propagate the script's exit code
+        env:
+          UPDATE_EXIT_CODE: ${{ steps.update.outputs.exit_code }}
+        run: exit ${UPDATE_EXIT_CODE}