Why are coefficients in tensor product bases represented the way they are?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Refactoring
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- julia
- Ambito
- performance
Direzione di ricerca
Non vengono indicati file, test o punti di ingresso. Inizia individuando la rappresentazione dei coefficienti della base del prodotto tensoriale e la costruzione dell’operatore di differenziazione, quindi confronta, per l’esempio di Chebyshev, l’ordinamento impacchettato attuale con l’archiviazione come matrice o con l’archiviazione rimodellata. Il lavoro è completato quando viene documentata la motivazione oppure viene concordata una modifica fattibile della rappresentazione che affronti i costi di memoria e prestazioni segnalati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
If you have a basis of Chebyshev Polynomials, for example, that looks like this:
[T00 T01 T02;
T10 T11 0 ;
T20 0 0 ]
These are stored like so
[T00, T01, T10, T02, T11, T20]
My question is: why? Would it not be more natural to simply keep using the matrix? Or perhaps reshape the matrix to a vector, so columns are concatenated together?
In my case, using the matrix directly means I don't have a differentiation operator with 1e12 entries, but rather one with 1e6 entries, which is the difference between feasible and impossible. (The reduction occurs because in the matrix way of doing things, I can use the 1D operators on each column/row, which amounts to a simple matrix matrix multiplication).
Of course, this comes at the cost of doubling the memory, but it seems more than worth it to double the memory at this stage if you can save many orders of magnitude in memory/time when building operators and applying them.
- Lingua principale
- Julia
- Stelle
- 13
- Fork
- 13
- Merge medio
- 23h
- PR unite (30g)
- 2
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 JuliaApproximation/ApproxFunBase.jl
-
tagbot-manual
Difficoltà 1/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
JuliaApproximation/ApproxFunBase.jl#389 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
JuliaApproximation/ApproxFunBase.jl#81 · 10 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
JuliaApproximation/ApproxFunBase.jl#8 · 1 reazione ·
Tutte le issue di JuliaApproximation/ApproxFunBase.jl
Issue simili
-
tagbot-manual
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
tshort/StaticCompiler.jl#191 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
SciML/SciMLSensitivity.jl#1703 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
JuliaGPU/GPUCompiler.jl#1008 ·
I maintainer di solito rispondono entro 1 giorno
-
`biggs6` disagrees with CUTEst and is unbounded belowForse già presa @timholy l’ha presa 1 giorno fa. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Cannot set point coordinates with `Range`s (or arbitrary arrays) using `Makie.Resampler` in `heatmap`Forse già presa @ffreyer l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno