Summary
The README feature matrix marks backend availability per function with ✅️ (native), 🔄 (CPU fallback), or blank (no implementation). That tells you whether a function runs on Dask or GPU. It doesn't answer the question #2415 cares about: what can a production user actually rely on?
This swaps the per-backend availability marks for per-backend tier emojis, so each cell says how production-ready that function is on that backend.
Proposed change
Use the five tiers from #2415, mapped to emojis:
- ✅ stable
- 🔼 advanced
- 🧪 experimental
- 🔧 internal
- 🚫 unsupported
- blank = no implementation on that backend
Each implemented backend cell carries that backend's tier. A cell that used to be a CPU fallback (🔄) takes the tier of the fallback path: advanced, since a fallback is a documented execution mode, not native parity. Cells with no implementation stay blank.
How tiers were assigned
Documentation only, no code changes. The tiers are a best-guess read of the code and its tests, using the conservative rubric from #2415: stable needs a correctness baseline plus cross-backend parity evidence for that backend; the NumPy path can be stable while the Dask/GPU paths are still advanced; a passing unit test on its own doesn't make something stable.
This is a first pass at the README presentation, not the machine-readable registry #2415 describes. When that registry lands, the table can be generated from it instead.
Part of #2415.
Summary
The README feature matrix marks backend availability per function with ✅️ (native), 🔄 (CPU fallback), or blank (no implementation). That tells you whether a function runs on Dask or GPU. It doesn't answer the question #2415 cares about: what can a production user actually rely on?
This swaps the per-backend availability marks for per-backend tier emojis, so each cell says how production-ready that function is on that backend.
Proposed change
Use the five tiers from #2415, mapped to emojis:
Each implemented backend cell carries that backend's tier. A cell that used to be a CPU fallback (🔄) takes the tier of the fallback path: advanced, since a fallback is a documented execution mode, not native parity. Cells with no implementation stay blank.
How tiers were assigned
Documentation only, no code changes. The tiers are a best-guess read of the code and its tests, using the conservative rubric from #2415: stable needs a correctness baseline plus cross-backend parity evidence for that backend; the NumPy path can be stable while the Dask/GPU paths are still advanced; a passing unit test on its own doesn't make something stable.
This is a first pass at the README presentation, not the machine-readable registry #2415 describes. When that registry lands, the table can be generated from it instead.
Part of #2415.