KernelFunctions.jl
                                
                                 KernelFunctions.jl copied to clipboard
                                
                                    KernelFunctions.jl copied to clipboard
                            
                            
                            
                        Revisit Multi-Output Support Naming Conventions
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:
- MOvs- MultiOutput. 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.
I like the isotopic prefix, it has a clear meaning. The first time I read the documentation and the code for MOinputs it took me quite a while to understand why there was such a construct in the package. I didn't immediately understand that it was an util function for the isotopic case. The prefix helps with that, and even if a new user does not know what it means at least it has a word to google.
In fact, I even suggested renaming it here
Should we create a new type for the inputs of Multioutput kernels, and then create a new method for
FiniteDifferences.to_vecto dispatch on, as well as newChainRulesrules for this type of kernels?Such type could be called
MOInput, and the currentMOInputcould be renamed to something likeAllObservedMOInputorFullyObservedMOInput.
because just MOInput didn't make much sense.
On thing I was imagining here was some graphics explaining isotopic vs heterotopic vs "some missing data". Perhaps a picture of a matrix with the missing data highlighted or something? Obviously doesn't help with the naming, but would be good to have in the docs.