Specifying Domain of Kernels

Abierto
  • ¿Algo no está bien?
#382 13 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
julia
Área
machine-learning

Línea de trabajo

Comienza comparando Proposal 1 y Proposal 2 con los constructores de kernels existentes y los lugares actuales en los que los kernels aceptan una métrica. Traza cómo se necesita la información del dominio para las operaciones de kernels y la construcción de Random Fourier Feature. Se considera terminado cuando el proyecto tenga un diseño acordado para la especificación del dominio y las interfaces de los kernels afectadas lo sigan de forma coherente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Proposal 1

# Euclidean domain with D dimensions.
struct Euclidean
    D::Int
end

dim(domain::Euclidean) = domain.D

"""
    DomainKernel{Tkernel<:Kernel, Tdomain}

A kernel with additional information specifying the domain of the kernel.
This provides a complete specification of a kernel, whereas most kernels by themselves do
not provide the domain information necessary to construct e.g. Random Fourier Feature
approximations to themselves.
"""
struct DomainKernel{Tkernel<:Kernel, Tdomain} <: Kernel
    kernel::Tkernel
    domain::Tdomain
end

kernelmatrix(k::DomainKernel, x::AbstractVector) = kernelmatrix(k.kernel, x)

function kernelmatrix(k::DomainKernel, x::AbstractVector, x′::AbstractVector)
    return kernelmatrix(k.kernel, x, x′)
end

Proposal 2

struct AutoEuclidean end

struct Euclidean
    D::Int
end

struct SEKernel{Tmetric_space} <: Kernel
    metric_space::Tmetric_space
end

SEKernel() = SEKernel(AutoEuclidean())

This version would be quite breaking, but I'd rather we didn't worry about that, and instead focus on which one we think constitutes the better solution, and go from there.

I'm personally leaning more towards the second option -- it feel cleaner on some level. The DomainKernel idea would probably work, but my gut is that it'll be messy in practice. You would have to write

DomainKernel(SEKernel(), Euclidean(5)) + 0.5 * with_lengthscale(DomainKernel(SEKernel(), Euclidean(5)))

vs

SEKernel(Euclidean(5)) + 0.5 * with_lengthscale(SEKernel(Euclidean(5)))

My feeling is that the latter is easier to read.

It also avoid some redundancy -- we currently let users specify the metric in a lot of kernels. Having the metric and domain of the kernel specified in different places feels strange to me.

Lenguaje dominante
Julia
Estrellas
276
Forks
42
Merge medio
3 d 12 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de JuliaGaussianProcesses/KernelFunctions.jl

Todos los issues de JuliaGaussianProcesses/KernelFunctions.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.