Maybe AbstractDifferentiation should shrink to a collection of names?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 20/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- julia
- Ambito
- backend-api-design
Direzione di ricerca
Leggere l’interfaccia attuale di AbstractDifferentiation.jl e confrontarla con il prototipo collegato di DifferentiationInterface.jl. L’issue non indica alcun file, test, punto di ingresso o criterio di accettazione specifico, quindi il primo passo consiste nel chiarire l’ambito proposto e definire cosa dovrebbe includere una riprogettazione riuscita incentrata sul backend.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I increasingly feel like all the heavy lifting should be done by backends, and AbstractDifferentiation.jl should just define common names.
Whenever we do something that a backend does not support, or when we recode it instead of letting the package do it, we introduce correctness, readability or performance issues. Some examples:
- additional closures with type instabilities (#109, #121)
- hard-to-parse macros (#123)
- vicious tuples (#99, #53)
- no exploitation of optimized backend code (#54)
Moreover, the complexity of the package also makes it very hard to push Enzyme support over the finish line (#84), which is arguably the biggest missing feature.
@adrhill and I are working on a prototype to play with this idea:
https://github.com/gdalle/DifferentiationInterface.jl
It may or may not be merged into AbstractDifferentiation, depending on what the team here thinks. The main caveat I see is that higher order cannot be well supported with an empty shell, but for gradients and JVPs/VJPs it should be close to optimal.
- Lingua principale
- Julia
- Stelle
- 138
- Fork
- 18
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
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 JuliaDiff/AbstractDifferentiation.jl
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
JuliaDiff/AbstractDifferentiation.jl#132 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
JuliaDiff/AbstractDifferentiation.jl#131 · 2 commenti · 1 reazione ·
-
Configurable ForwardDiff tagApertafeature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
-
Get rid of ugly macro?Apertaquestion
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
JuliaDiff/AbstractDifferentiation.jl#123 · 6 commenti ·
Tutte le issue di JuliaDiff/AbstractDifferentiation.jl
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
JuliaGPU/KernelAbstractions.jl#897 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
oscar-system/GAP.jl#1455 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
JuliaAI/MLJTransforms.jl#85 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
SciML/OrdinaryDiffEq.jl#4875 ·
I maintainer di solito rispondono entro 4 giorni