Unify `Matrix` and `Tensor` internals
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by locating the existing C implementations and the Python Matrix and Tensor entry points, then review the existing Matrix tests, examples, and downstream C ABI expectations. Done means both types share representation and inner loops while Matrix keeps its public Python behavior, rank-2 algebra, performance, and compatibility; the open conversion and interoperability questions also need decisions.
Written by the indexing model from the issue text.
Description
Problem
After the Tensor work lands, the project carries two parallel C implementations of "dense array of doubles": one rank-2 (Matrix), one N-D (Tensor). Every arithmetic op, every aggregate, every cross-interpreter round-trip exists twice. New work has to be added in both places, or one side drifts. This is sustainable for one release; it is not sustainable as a long-term shape for the library.
Desired functionality
The two types share a single C representation and a single set of inner loops. Matrix becomes the rank-2 face of that shared machinery. The Python-level Matrix API — constructor, methods, return types, repr, type identity — looks identical to today from the outside; existing user code, existing examples, and existing downstream C consumers keep working unmodified.
Constraints
- Zero public API breakage. Every existing
Matrixtest, every example, every downstream C ABI consumer must keep working unchanged. - No measurable performance regression on
Matrix-shaped workloads. Matrixkeeps its own Python type.isinstance(x, Matrix)keeps working.- Rank-2-only algebra (matmul, transpose,
T, axis-0 / axis-1 aggregate sugar) stays onMatrix.
Out of scope
Generalising rank-2 algebra onto Tensor (matmul on Tensor, batched matmul, transpose(axes=...), swapaxes). Removing or renaming any public Matrix surface. Treating Matrix as deprecated.
Open questions
- Whether
MatrixandTensorshould be silently interchangeable in each other's arithmetic dunders, or whether the user has to step through an explicit conversion. - Whether to expose explicit
Matrix.to_tensor()/Tensor.to_matrix()helpers regardless.
- Dominant language
- Python
- Stars
- 184
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/bocpy
-
Difficulty 3/5 1-2 days Newbie friendliness 63/100
-
design
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
design
Difficulty 5/5 Over a week Newbie friendliness 28/100
-
maths
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
maths
Difficulty 5/5 Over a week Newbie friendliness 45/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100