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:
grammar_kwargs={'base_kernels_to_exclude': ['constant']}
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.
Currently there is a kind of duality in the naming used internally:
gpflowhas 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 inkerndiscby the_kernelsmodule, which maintains a dict ofkernel_name.lower(): kernel_classmappings. This is useful for general coding, but also for grammar definition: The_grammar_duvenaudallows 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
gpflowis questionable though.