`lax::UPLO` references column-major layout
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Start with ndarray-linalg/src/eigh.rs around line 127 and reproduce the supplied Rust example using both UPLO variants. Read the UPLO documentation and compare the behavior for the array layouts described; done requires a decided, documented strategy for layout handling, including the tuple-of-arrays case.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hello everyone, thanks for the great work.
Disclaimer: I'm new to LAPACK & scientific computing in general, apologies if what follows is not perfectly rigorous.
I've noticed that the UPLO flag does not necessarily do what we expect, in the sense that it references the column-major alignment of the data. In particular, I'm not sure this aligns with newcomers' expectations.
To wit, in the following example:
extern crate ndarray;
extern crate ndarray_linalg;
use ndarray::*;
use ndarray_linalg::*;
fn main() {
// A very clearly upper-diagonal matrix
let a = arr2(&[[3.0, 1.0, 1.0], [0.0, 3.0, 1.0], [0.0, 0.0, 3.0]]);
// Works with UPLO::Lower, not UPLO::Upper...
let (e, vecs) = a.eigh(UPLO::Lower).unwrap();
println!("eigenvalues = \n{:?}", e);
println!("V = \n{:?}", vecs);
let av = a.dot(&vecs);
println!("AV = \n{:?}", av);
}
Using UPLO::Upper does not work, even though the matrix is clearly upper-diagonal in ndarray-world.
It looks like this stems from this method, perhaps we should transpose uplo in that case? Note that in the case of a tuple of arrays, we should probably assert that both arrays have the same layout, otherwise it does not make sense to call uplo.t().
It might make sense to decide that UPLO is column-major only, and leave the responsibility to the caller. But in that case I think we should document that behaviour in UPLO's documentation.
I'm happy to propose a PR, let me know which strategy seems best to you.
- Lingua principale
- Rust
- Stelle
- 452
- Fork
- 95
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rust-ndarray/ndarray-linalg
-
Thin SVD Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 38/100
rust-ndarray/ndarray-linalg#414 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
rust-ndarray/ndarray-linalg#413 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
rust-ndarray/ndarray-linalg#404 ·
-
SIGSEGV on qr decomposition Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
rust-ndarray/ndarray-linalg#402 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
rust-ndarray/ndarray-linalg#401 · 2 reazioni ·
Tutte le issue di rust-ndarray/ndarray-linalg
Issue simili
-
bug github_actions
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
registrystack/registry-stack#1393 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
rocky-data/rocky#2181 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Apertabot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
midnightntwrk/midnight-indexer#1557 ·