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
{{ message }}
This repository has been archived by the owner on Dec 3, 2019. It is now read-only.
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)?
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
The text was updated successfully, but these errors were encountered: