Add graph generation algorithm for Knapsack problems

[Matti02co]

Description:

This pull request adds a function to generate a directed acyclic graph (DAG) representation of a classic 0/1 Knapsack problem.
The graph representation enables solving the problem using shortest/longest path algorithms in DAGs, providing an alternative approach to traditional dynamic programming solutions.
Each path from the source node s to the sink node t corresponds to a valid subset of items.

Key points:

Input:

• capacity — maximum knapsack capacity (integer)

• weights — list of item weights (list of integers)

• values — list of item values (list of integers)

Output:

• List of edges, each represented as a dictionary containing "from", "to", "cost", and "label".

Implements Python type hints and doctests.

Code style follows PEP 8 and is Black-formatted.

Passes Ruff tests.

• 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:

• I have read 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.
• 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.
• All functions have doctests 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: "Fixes #ISSUE-NUMBER".

[cclauss]

@priya-sundaram-dev, please review. I have not done much with the knapsack, so perhaps I am missing something, but is this really adding educational value? When would someone reach for this algorithm?

There are tons of single-letter variable names, which make the logic tricky to follow... w vs. weight vs. weights ... Is n even needed?

Functions return dict[str, Any] which provides the caller no help. Would a dataclass or a typed dict make more sense?

[priya-sundaram-dev]

Reviewed, @cclauss — I share your skepticism. The idea is genuinely nice: reduce 0/1 knapsack to a shortest-path problem on a layered DAG (each layer = one item, each node = a (item, weight-used) state, "take" edges carry -value). Connecting knapsack to SPP is a real teaching moment. But as submitted I don't think it's mergeable, for a few concrete reasons:

1. It never actually solves anything. generate_knapsack_graph() only emits a list of edges — there's no shortest-path call, so a reader can't see knapsack solved. An "algorithm" file that stops at building the input to another algorithm is incomplete. To add educational value it should run (e.g.) Bellman-Ford over the DAG and return the optimal value/selection, ideally cross-checked against the classic DP in a doctest.

2. Types, as you noted. list[dict[str, Any]] with stringly-typed keys "from"/"to"/"cost"/"label" gives the caller no help and defeats type checking. A NamedTuple/dataclass Edge(frm, to, cost, label) would be self-documenting and mypy-friendly.

3. Inconsistent node identities. Interior nodes are tuples (i, w) but source/sink are strings "s"/"t" — mixing types in the same graph is a smell.

4. Reference is a personal repo (Matti02co/graph-based-scheduling). TheAlgorithms prefers a self-contained implementation with an authoritative reference (Wikipedia "Knapsack problem" / "Shortest path").

5. Minor: single-letter w/n, and skip-edges are emitted from every (i, w) including unreachable states (harmless but noisy).

Verdict: the DAG-to-SPP framing is worth encouraging, but this needs (1) an actual solve step with a doctest verifying it matches the DP result, and (2) a typed edge structure. Given the pre-Oct-1 push, I'd request changes; if @author can't turn it around, close with a pointer to reopen once it solves the problem end-to-end. Happy to re-review if they add the solver.