KernelFunctions.jl icon indicating copy to clipboard operation
KernelFunctions.jl copied to clipboard

Revisit Multi-Output Support Naming Conventions

Open thomasgudjonwright opened this issue 4 years ago • 2 comments

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:

  • MO vs 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, mokernel and weights instead of g, e and A for the slfm
  • the LinearMixingModelKernel is a kernel, not a model. Maybe it should be renamed LinearMixingKernel for eg. I think we've all agreed on this already.

thomasgudjonwright avatar Jul 08 '21 17:07 thomasgudjonwright

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_vec to dispatch on, as well as new ChainRules rules for this type of kernels?

Such type could be called MOInput, and the current MOInput could be renamed to something like AllObservedMOInput or FullyObservedMOInput.

because just MOInput didn't make much sense.

david-vicente avatar Jul 13 '21 16:07 david-vicente

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.

willtebbutt avatar Jul 13 '21 16:07 willtebbutt