You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is a kind of duality in the naming used internally:
gpflow has it's own naming scheme, which capitalizes kernel names. However they go as far as also using camel case (ArcCosine) and upper case (RBF). Currently this is then abstracted in kerndisc by the _kernels module, which maintains a dict of kernel_name.lower(): kernel_class mappings. This is useful for general coding, but also for grammar definition: The _grammar_duvenaud allows for kernels to be excluded from being a base_kernel. These can be passed by passing:
Currently there is a kind of duality in the naming used internally:
gpflow
has it's own naming scheme, which capitalizes kernel names. However they go as far as also using camel case (ArcCosine
) and upper case (RBF
). Currently this is then abstracted inkerndisc
by the_kernels
module, which maintains a dict ofkernel_name.lower(): kernel_class
mappings. This is useful for general coding, but also for grammar definition: The_grammar_duvenaud
allows for kernels to be excluded from being abase_kernel
. These can be passed by passing:as a parameter to
discover
. Here it is easier for a user to just use lower case kernel names, than remembering all the different casing options.Whether this justifies deviation from
gpflow
is questionable though.The text was updated successfully, but these errors were encountered: