# The kernel tag is a mess – should it be changed? [duplicate]

The unfortunate collision of the word "kernel" as in "kernel density estimate" and the separate use as in "reproducing kernel Hilbert space" is making the tag kind of confusing.

The tag wiki summary has as its second sentence

DO NOT USE this tag for [kernel-trick] which is reserved for kernel methods in machine learning.

(as was @gung's suggestion here). But the first page of the "active" page for the tag currently shows only 4/15 questions about kernel smoothing and the remaining 11 about RKHS kernel functions. So it seems that the outcome of this discussion from last fall wasn't enough to clean up the tag.

The current space of kernel-related tags seems to be:

• , supposed to be for KDE-style kernel functions but in practice a mix of both (264 questions)
• , for RKHS-style kernel functions and related issues (85 questions)
• , for KDE in general (78 questions)
• , 5 questions of which 4 are about Nadaraya-Watson kernel regression (analogous to KDE) and 1 is about RKHS kernels

I think the name isn't the most intuitive name when you're thinking about kernel methods, especially when there's the tag popping up first. So I propose either:

1. renaming to
2. completely removing and sorting it into and as appropriate.

In either case, people who should be using will then hopefully pause after typing in "kernel", see two options, and hopefully read the tag summaries and pick the correct one.

I'm happy to do that sorting (a few at a time during low-traffic times).

• Do we need [kernel-regression]? Would it be enough to have [kde] & [regression]? – gung - Reinstate Monica Apr 9 '15 at 2:26
• Yeah, [kernel-regression] is pedantically distinct from [kde] but I don't see a practical reason to distinguish it. – Dougal Apr 9 '15 at 2:26
• +1, Thanks for bringing this up again. After my question (that you link to) I went through all PCA questions and retagged all kernel PCA ones to [kernel-trick]. But I did not touch kernel SVM questions etc. I think we should have two tags in the end: [kernel-trick] and [kernel-smoothing]. – amoeba Apr 9 '15 at 8:54
• As a note: I've been slowly going through and categorizing the [kernel] tag, but I decided tonight to just sort it entirely into [kernel-trick] and [kernel-density-estimation] as appropriate, removing [kernel] as I go. I think that should be the easiest path to ending up where we want to be, though it'll take a while to get there. (It's a shame simply retagging bumps to the homepage....) – Dougal Apr 23 '15 at 6:01

I am posting this answer mainly to try to kindle some further discussion.

As I wrote above, after posting my question (that you link to) I went through all PCA questions and retagged all kernel PCA ones to [kernel-trick]. But I did not touch kernel SVM questions. I think that manual retagging all such machine learning questions to [kernel-trick] would be a good thing to do, and if you are up to it -- go ahead.

(This will have an added benefit that you will be able to use this opportunity to edit, close, or answer some of the questions you go through.)

The more difficult question is what to do with the remaining questions, and here I am not sure. I agree with @gung that [kernel-regression] can be removed. Leaving [kernel] tag intact will make people use it instead of [kernel-trick], as it is currently happening every now and then. So I think the best course of action would be to merge [kernel], [kernel-density-estimate]=[kde], and [kernel-smoothing] into one tag that starts with [kernel-...].

I guess [kernel-density-estimate] might be the best candidate, but I am not sure.

Here are some possibilities:

• I don't quite follow your suggestion. Are you saying $\{$[kernel]$,$ [kernel-density-estimate]$\}\rightarrow$ [kde], & then that [kernel-smoothing]$\rightarrow$[kernel-density-estimate]? – gung - Reinstate Monica Apr 14 '15 at 16:48
• Apologies for confusion. My suggestion is that we end up with two tags: one is [kernel-trick] and another is [kernel-something] that corresponds to kde; perhaps it can be [kernel-density-estimate]. Then [kernel-smoothing] and [kde] can be both synonyms to [kernel-density-estimate]. I am not sure what to do with the [kernel] tag itself; it feels wrong to make it a synonym for something more specialized. Perhaps we can simply eliminate this tag via manual retagging and see if it ever reappears... What do you think? – amoeba Apr 14 '15 at 22:06
• The tag will need to be destroyed by a moderator. That's the only real solution. I took the liberty of editing your post to make the suggestions explicit. If you don't like it, roll it back w/ my apologies. You may also prefer to edit it, if I got some part wrong. On a different note, people seem to prefer [kernel-density-estimate], but we could go w/ the shorter [kde] instead if we wanted. As long as the longer version exists as a synonym, people wouldn't have trouble finding it. I'm not sure where I stand on that, but it's a possibility. – gung - Reinstate Monica Apr 15 '15 at 3:49
• What does it mean for the tag "to be destroyed" by a moderator, @gung? I have never encountered such a procedure. Does it mean that the tag gets deprecated and nobody can post a question with this tag anymore? – amoeba Apr 29 '15 at 9:59
• I'm not a moderator, @amoeba, so I don't know exactly. But the mods can blacklist a tag so that it can never be used again. This is more extreme, & permanent, than making a tag a synonym. If we don't make [kernel] a synonym, it won't disappear & will certainly be used again. – gung - Reinstate Monica Apr 29 '15 at 14:36

A similar thing happens with the "clustering" tag on SO. One third want to load-balance their web server, one third are about database clusters, and one third is about cluster analysis.

IMHO stackoverflow needs some "this tag is ambiguous, choose a better tag" function. People do not read tag descriptions (the Android app doesn't display them anyway). If a user types "kernel" he should have to choose from KDE, kernel-trick, etc. and not be allowed to use the ambiguous version. (Aliases don't work - on SO clustering is aliased to cluster-analysis, and we get plenty of mistaggings there. Instead, multiple alternatives should be offered: load-balancing won't turn up when a user searches for clustering either!)