Skip to content

Fix/62 view matvec and naming - #356

Open
Thiago316316 wants to merge 2 commits into
kmolan:mainfrom
Thiago316316:fix/62-view-matvec-and-naming
Open

Thiago316316 wants to merge 2 commits into
kmolan:mainfrom
Thiago316316:fix/62-view-matvec-and-naming

Conversation

@Thiago316316

Copy link
Copy Markdown
Contributor

What & why

impl Mul<VectorView<', COLS, T>> for MatrixView<', ROWS, COLS, T> to match the the owned counterpart.
Vector::get / get_mut take i: usize; rename the parameter to index so it's consistent with the repository.

issues #83

Checklist

  • cargo test + cargo clippy --all-targets clean locally
  • New public APIs have a doc example
  • No unwrap/expect/panic on library paths (typed errors instead)

Thiago316316 and others added 2 commits September 17, 2026 22:56
`Matrix` has had `Mul<Vector>` since before the views landed, but the
borrowed side had no counterpart, so a product over a view had to be
written out of `try_row` and `dot` at every call site.

`MatrixView<ROWS, COLS> * VectorView<COLS>` now yields an owned
`Vector<ROWS>`, reading both operands where they lie. It is infallible
where the rest of the view surface is not: the shapes are const
parameters settled at the call site rather than indices supplied at run
time, so unlike `Index` there is no miss to report. The body stays total
without an assertion, the way `VectorView::dot` already handles its own
impossible misses, which keeps the no-panic rule intact.

The property test uses the owned operator as its oracle over random
matrices in both orientations. Both accumulate rows in the same order,
so the two agree bit for bit and the assertion is exact.

Also renames `Vector::get` / `get_mut`'s `i` parameter to `index`, and
the two crate-internal unchecked accessors with it, so the rendered docs
name what they take.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`Mul` would have been the only infallible call on a view, and the only
place the surface stopped reading as `try_*`. The failure it elided
cannot occur, but a reader has to work out why before trusting that, and
the operator would have been the first `core::ops` impl on a view — an
invitation to ask for `Add`, `Sub`, and `Neg`, which would allocate an
owned result for no gain.

`MatrixView::try_mul` returns `Result<Vector<ROWS, T>, LinalgError>` like
everything else here. The doc says outright that `OutOfBounds` cannot be
returned, so nothing is hidden, and the module doc no longer needs a
paragraph excusing one operation from its own rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant