Revisit Multi-Output Support Naming Conventions
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
- machine-learning
Direzione di ricerca
Inizia leggendo la discussione in PR #310 e il thread collegato, quindi esamina src/mokernels/slfm.jl, in particolare i campi del tipo composito. Il lavoro è completo quando il progetto dispone di una convenzione di denominazione documentata e concordata per i tipi con output multipli, gli helper, i campi e LinearMixingModelKernel.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Two new multi-output input types are being added and the PR sparked some debate/discussion surrounding their names and the wider spread naming conventions that have been adopted in KernelFuntions. The main thread discussing these can be found [here].(https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/pull/310#discussion_r661490968).
Some starting points:
MOvsMultiOutput. Concise or explicit?- Do we like the prefix
isotopic? Is it too jargony?
Quote from paper linked above:
In the geostatistics literature, if each output has the same set of inputs the model
is called isotopic
Pros:
It has a specific meaning in this context, clearly identifying what it is
Cons:
Might scare users off, lengthens names
- Relating to the PR linked above, how do we make these accessible? Less "wordy" helpers? What do we call those?
- Should composite type field names have more descriptive names?
eg.kernels,mokernelandweightsinstead ofg,eandAfor the slfm - the
LinearMixingModelKernelis a kernel, not a model. Maybe it should be renamedLinearMixingKernelfor eg. I think we've all agreed on this already.
- Lingua principale
- Julia
- Stelle
- 276
- Fork
- 42
- Merge medio
- 1g 13h
- PR unite (30g)
- 1
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
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
JuliaGaussianProcesses/KernelFunctions.jl#609 · 1 commento ·
-
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
Tutte le issue di JuliaGaussianProcesses/KernelFunctions.jl
Issue simili
-
documentation
Difficoltà 2/5 Mezza giornata Idoneità per principianti 65/100
I maintainer di solito rispondono entro 6 giorni
-
broken links in docsAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
JuliaPhysics/BeamletOptics.jl#127 ·
I maintainer di solito rispondono entro 1 giorno
-
Chains resumed from `initial_state` take `num_warmup + 1` warm-up stepsForse già presa @thevolatilebit l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
TuringLang/AbstractMCMC.jl#220 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno