lobpcg::TruncatedSvd maps non-converged LOBPCG results to Ok, hiding convergence failure
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
Piste de recherche
Start in src/lobpcg/svd.rs at TruncatedSvd::decompose and inspect LobpcgResult handling around lines 162-172, then review the result type and the maxiter setup around line 105. Check src/generate.rs and issue #336 for the separate RNG concern. Done means non-convergence is no longer silently reported as success, with the chosen result API covered by appropriate tests.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Summary
lobpcg::TruncatedSvd::decompose maps a non-converged LOBPCG result onto Ok(..), so callers cannot distinguish a converged decomposition from a failed one and may silently receive wrong singular values.
Version inspected: ndarray-linalg 0.17.0 (source from crates.io).
Where
match res {
LobpcgResult::Ok(vals, vecs, _) | LobpcgResult::Err(vals, vecs, _, _) => {
Ok(TruncatedSvdResult {
problem: self.problem,
eigvals: vals,
eigvecs: vecs,
ngm: n > m,
})
}
LobpcgResult::NoResult(err) => Err(err),
}
LobpcgResult::Err(..) carries the error as its fourth field and it is dropped on the floor. Returning the partial result is reasonable; giving the caller no way to learn that it is partial is the problem.
Contributing factor: maxiter defaults to problem.len_of(Axis(0)) * 2 (svd.rs:105), which is a small iteration budget for small inputs — exactly where I measured the worst errors in the sibling implementation.
Evidence
I want to be straightforward about what I did and did not run.
Verified by source inspection in ndarray-linalg 0.17.0: the LobpcgResult::Err(..) => Ok(..) mapping above, and the maxiter default.
Not executed against ndarray-linalg: I do not have a LAPACK backend configured locally, so I could not run a reproduction through this crate.
Measured in linfa-linalg 0.2.1, whose lobpcg::TruncatedSvd is the same algorithm with the same structure (Err((_, Some(Lobpcg{..}))) => Ok(..), same 2 * n_samples default, same epsilon * correction * λ_max cutoff). Taking X = U diag(4, 3, 2, 1) Vᵀ with U (8×4) and V (4×4) built from Sylvester–Hadamard columns, so the singular values are exactly [4, 3, 2, 1] by construction:
k=1 returned Ok sigma=[4.0] max rel err=2.220e-16
k=2 returned Ok sigma=[4.0, 3.0] max rel err=4.441e-16
k=3 returned Ok sigma=[3.94368, 2.67522, 1.477172] max rel err=2.614e-1 <== WRONG
k=4 returned Ok sigma=[4.0, 3.0, 2.0, 1.0] max rel err=2.517e-15
A 26% error reported as success, with neighbouring block sizes exact to machine precision. I would expect the same behaviour here given the shared structure, but I have not confirmed the exact numbers under LAPACK — if that distinction matters to you, treat the code-level finding as the claim and the numbers as indicative.
Filed in parallel as rust-ml/linfa-linalg#20.
Secondary: the result is not reproducible
decompose initialises its starting block with generate::random(..) (svd.rs:132), and generate::random uses thread_rng() (src/generate.rs:36). There is no new_with_rng equivalent, so successive runs of the same program on the same input can land on different subspaces and different component signs. Combined with the silent non-convergence above, that makes the failure intermittent as well as quiet. This overlaps with #336.
Suggested remedies
- Surface convergence to the caller — e.g. a
converged: boolor the residual norms onTruncatedSvdResult— rather than discarding the error. - Or return
Errby default, with the partial result available through an explicit opt-in. - Consider a seedable entry point (
new_with_rng) so results are reproducible;linfa-linalghas one.
Glad to put up a PR if you have a preference on direction.
- Langage dominant
- Rust
- Étoiles
- 452
- Forks
- 95
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de rust-ndarray/ndarray-linalg
-
Thin SVDOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 38/100
rust-ndarray/ndarray-linalg#414 ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
rust-ndarray/ndarray-linalg#413 · 1 commentaire ·
-
Cyclically Tridiagonal Matrices?Ouverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
rust-ndarray/ndarray-linalg#404 ·
-
SIGSEGV on qr decompositionOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
rust-ndarray/ndarray-linalg#402 · 1 commentaire ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
rust-ndarray/ndarray-linalg#401 · 2 réactions ·
Toutes les issues de rust-ndarray/ndarray-linalg
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
wardian-app/Wardian#1603 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 2 jours
-
bug
Difficulté 1/5 1-3 heures Accessibilité débutants 72/100
peteonrails/voxtype#844 ·
Les mainteneurs répondent en général sous 1 jour
-
feature
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
uwuclxdy/clauth#107 · 1 commentaire ·
Les mainteneurs répondent en général sous 4 jours