Skip to content
This repository has been archived by the owner on Dec 3, 2019. It is now read-only.

Positive Definite vs Mercer #38

Open
Evizero opened this issue Sep 28, 2015 · 2 comments
Open

Positive Definite vs Mercer #38

Evizero opened this issue Sep 28, 2015 · 2 comments

Comments

@Evizero
Copy link
Contributor

Evizero commented Sep 28, 2015

I see that you treat positive definite kernels as being synonymous to mercer kernels, while as far as I understand there is a slight difference in that a mercer is more restrictive (e.g. continuity).

Was this an oversight, or a conscious design decision (for simplification maybe)?

source: here at 36:40

@trthatcher
Copy link
Owner

Hi there!

That was definitely an oversight. Most of the reading I did for this project was strictly from Harmonic Analysis on Semigroups (Christian Berg) which was focused on the properties and construction of positive definite and negative definite kernels - no mention of the Mercer subset.

Originally, I had an isposdef function that imported the one from base and was defined for the kernel type. However, in issue #26 there was concern about the difference in definition of a positive definite kernel and a positive definite matrix (ie positive definite kernel is a generalisation of a positive semidefinite matrix). The suggestion was the ismercer function instead. I went along with it having not been aware of the continuity restriction.

I'll be updating this package soon. I'm indifferent on the naming of functions as long as their implied function is consistent with literature. Clearly, this is not.

What are your thoughts?

@Evizero
Copy link
Contributor Author

Evizero commented Oct 1, 2015

I completely missed the discussion about the base function. Hard to say now what the cleanest solution for the naming would be. What is true as far as I know is that the conditions for Mercer's theorem are equivalent to requiring that for any finite subspace of a compact space, the corresponding matrix is positive semi-definite. So I too think that extending the base function isposdef is a bad idea consistency wise.

Probably the best course of action is to leave it as it is for now and see on which edge cases the current interface with ismercer "breaks" (if it even does).

I will work with this package very closely very soon in the context of support vector machines. I am sure I'll have more educated suggestions once I really dig into the code.

Glad to hear you are still interested in maintaining this package! I am looking forward to helping out where I can

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants