Designing some test fakes
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- julia
- Ambito
- machine-learning, testing-qa
Direzione di ricerca
Inizia leggendo il post del blog collegato sull’interface testing e esaminando il modulo TestUtils del package, insieme ai test relativi a GP menzionati in AbstractGPs. Definisci il kernel composito proposto e raccolte di input validi in modo che supportino AD, producano matrici kernel numericamente definite positive ed evitino proprietà non garantite dall’interfaccia. Il lavoro è completato quando i fake e gli input riutilizzabili sono pubblicati per i test downstream e coprono questi requisiti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
We have decent enough interface tests in this package, but we don't have good choices for test fakes. See this blog for a description of what they are / why they're useful. The reason I think they're likely useful here is that if you're a package that consumes kernels, you currently have to pick a kernel + inputs to the kernel. Often, as for the tests involving a GP in AbstractGPs, it would be really useful if KernelFunctions just gave you a kernel and some collections of valid inputs for that kernel for which you could be confident that
- the kernel matrix produced is going to be positive definite (numerically)
- the kernel doesn't satisfy any more properties than the interface specifies. i.e. you probably want to be testing with a non-stationary kernel, that doesn't have unit variance etc to avoid accidentally depending on an edge case
Maybe we should publish in the TestUtils module some kind of weird composite kernel that we know isn't stationary etc, and that does play nicely with AD, in addition to some collections of inputs to the kernel that a downstream user can make use of.
Any thoughts as to whether this would be useful?
edit: link to blog post added
- Lingua principale
- Julia
- Stelle
- 276
- Fork
- 42
- Merge medio
- 2g 20h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
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 JuliaGaussianProcesses/KernelFunctions.jl
-
Future plans?Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
JuliaGaussianProcesses/KernelFunctions.jl#585 · 8 commenti · 3 reazioni ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
JuliaGaussianProcesses/KernelFunctions.jl#571 · 1 reazione ·
-
new kernel
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 25/100
JuliaGaussianProcesses/KernelFunctions.jl#533 · 1 reazione ·
Tutte le issue di JuliaGaussianProcesses/KernelFunctions.jl
Issue simili
-
io
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
JuliaGPU/GPUArrays.jl#837 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
bmad-sim/BeamTracking.jl#382 ·
I maintainer di solito rispondono entro 1 giorno