[WIP]Add a generic way to check kernel's input dimensions compatibility.

[sharanry]

Related PR #111

Please find a generic way to deal with dimensions of inputs to kernels as @willtebbutt and @devmotion had suggested in #111 .

I had to remove restrictions on input type for validate_dims to accommodate few test cases for TensorProduct.

If this setup is okay, I will proceed to apply similar checks to all kernels.

[willtebbutt]

I had to remove restrictions on input type for validate_dims to accommodate few test cases for TensorProduct.

@sharanry which test cases? Given that all collections of inputs should now be represented as AbstractVectors, I'm very surprised that this is an issue.

[sharanry]

@sharanry which test cases? Given that all collections of inputs should now be represented as AbstractVectors, I'm very surprised that this is an issue.

The 3rd iteration of this for loop.

[willtebbutt]

Hmmmm... @devmotion I'm assuming you wrote these particular tests? (possibly I refactored them blindly when introducing the everything-is-a-vector changes though). Specifically, what does an input [a, b] represent?

edit: is it meant to be interpreted as a length - length(a) * length(b) vector?

[devmotion]

Specifically, what does an input [a, b] represent?

It represents the same as (a, b), namely an input that consists of two components a and b (which can be of any (possibly different) type and do not have to be real numbers). We allow the individual kernels of TensorProduct to be saved as an arbitrary iterable container, and in the same way the implementation allows for arbitrary iterable container as inputs. This corresponds to the mathematical definition of a tensor product kernel: it is a kernel on a product space that is defined as a product of kernels evaluated on the individual spaces. Consistently, real-valued vectors as inputs are interpreted as an iterable container of scalar components.

Given that all collections of inputs should now be represented as AbstractVectors, I'm very surprised that this is an issue.

As far as I understand, the aim of the refactoring was to 1) get rid of the obsdim keyword arguments by encoding it in the ColVecs and RowVecs types, and 2) to interpret (::MyKernel)(x, y) always as evaluation of a kernel for a single data point and use kernelmatrix etc for evaluation of kernels on data sets. However, I guess we don't want to restrict the inputs to vectors only (since that, e.g., would rule out distributions as inputs or tuples of distributions and real vectors).

[willtebbutt]

🤦 I was misreading the tests and imagined a call to kernelmatrix in them.

As far as I understand, the aim of the refactoring was to 1) get rid of the obsdim keyword arguments by encoding it in the ColVecs and RowVecs types, and 2) to interpret (::MyKernel)(x, y) always as evaluation of a kernel for a single data point and use kernelmatrix etc for evaluation of kernels on data sets. However, I guess we don't want to restrict the inputs to vectors only (since that, e.g., would rule out distributions as inputs or tuples of distributions and real vectors).

You're completely correct.

It represents the same as (a, b), namely an input that consists of two components a and b (which can be of any (possibly different) type and do not have to be real numbers). We allow the individual kernels of TensorProduct to be saved as an arbitrary iterable container, and in the same way the implementation allows for arbitrary iterable container as inputs. This corresponds to the mathematical definition of a tensor product kernel: it is a kernel on a product space that is defined as a product of kernels evaluated on the individual spaces. Consistently, real-valued vectors as inputs are interpreted as an iterable container of scalar components.

👍

I think I probably just need to reproduce Sharan's error to figure out what's going on with the error he's seeing.

We're definitely going to need to be able to distinguish between a call to validate_kernel_dims with a single input and a vector of inputs. We can't do that by looking at the types alone, so it might be that we have to add some more information somehow.

edit: ah, yes, the issue is that validate_dims is getting called in the kernel evaluation function, rather than kernelmatrix. validate_dims was written for use with kernelmatrix (and related functions) rather than kernel evaluation. @sharanry as discussed above, we're going to need to modify the functionality somehow so that we can determine whether the call to validate_dims is coming from kernel evaluation or kernelmatrix and friends, so that we can dispatch appropriately. The simplest way to do this would be to write a bunch of extra functions that mirror the current validate_dims functionality, but expect individual inputs rather than vectors. That's a bit ugly though...

[willtebbutt]

@sharanry what's the status of this?

[willtebbutt]

This is definitely stale, so I'm closing. Please feel free to re-open if you wish to revive.