24
$\begingroup$

Please post your tag synonym suggestions as new answers in this thread, one answer per suggestion. Upvote answers where you believe that the suggested tags should be made synonyms, and downvote answers where you believe the tags should remain separate. Well upvoted suggestions will be eventually implemented by the moderators (and then the corresponding answers will be deleted).

$\endgroup$
  • 7
    $\begingroup$ @whuber, if this is inappropriate or unhelpful, then I can delete it, but my goal is the opposite: I don't want you (or the other mods) to have to spend time thinking about this & doing a lot of extra research. I'm hoping to bring this to the attention of the community, which, by voting (commenting, etc), will have done all of that for you guys. Nb, w/ respect to lme & multilevel, I'm not sure anyone will have the requisite upvotes--there have only been 3 questions w/ multilevel, according to it's page. $\endgroup$ – gung - Reinstate Monica♦ Jun 7 '12 at 16:59
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – whuber♦ Jan 21 '16 at 14:55
6
$\begingroup$

$\leftarrow$

Strictly speaking, this isn't a synonym. The Newey-West estimator is a specific instance of a robust standard error estimator. That is, this is a set-subset relation. People should feel free to disagree with this suggestion on that basis. However, I question whether they are distinct enough that people are going to want information (i.e., search for) on only one without the other. I further wonder whether there is sufficient interest to justify it: it was created in Sep 2011, and categorizes 27 questions so far, although no doubt there will be more eventually. Robust SE seems to have been created more recently (April 2014), but to have collected nearly twice as many questions.

  • [robust-standard-error] has 49 threads, with an excerpt and wiki.
  • [neweywest] has 27 threads, at least a couple of which seem to be about robust SEs more generally rather than specifically only about the Newey-West estimator per se. It had neither an excerpt nor a wiki, but I just made an excerpt suggesting people use robust SE instead.

Updated with two more potential synonyms:

$\leftarrow$

$\leftarrow$

  • [sandwich] has 17 threads, with a good excerpt and wiki. One thread has both sandwich and robSE.
  • [clustered-standard-errors] has 79 threads, with a good excerpt and wiki. The excerpt specifies that this is a subset of sandwich estimators. Three questions have both clustSE and robSE; one thread has clustSE and sandwich.
$\endgroup$
  • $\begingroup$ This sounds reasonable, but I know almost nothing about these topics and don't think I can judge. In particular, I am wondering if we have other tags that are examples of robust standard error estimators? Or is Newey-West the only such tag? If so, does it correspond to Newey-West being the most popular one? $\endgroup$ – amoeba says Reinstate Monica Jan 30 '17 at 19:33
  • $\begingroup$ For example, is [sandwich] also a subset of [robust-standard-error]? $\endgroup$ – amoeba says Reinstate Monica Jan 30 '17 at 19:34
  • $\begingroup$ Hmmm, good point @amoeba. [sandwich] is also a subset (it might be nearly a synonym, but I suspect there might be some kind of robust SE that isn't a sandwich estimator). [sandwich] is older than [rse], has 17 threads w/ a good excerpt & wiki (better than robSE). I could add it as another piece to this answer, but that might make it harder for people to distinguish the parts of the answer they approve vs disapprove, or could add as a separate answer. I would also probably be fine w/ [sandwich] as the master. $\endgroup$ – gung - Reinstate Monica♦ Jan 30 '17 at 20:14
  • $\begingroup$ Based on what you said, I think either we should map both, NW and sandwich, to robSE, or alternatively leave all of them alone. I cannot say what makes more sense, we should ask people with high rep in these tags. $\endgroup$ – amoeba says Reinstate Monica Jan 30 '17 at 20:21
  • $\begingroup$ Perhaps remove this from here & post this (together with [sandwich]) as a separate Meta question? $\endgroup$ – amoeba says Reinstate Monica Jan 30 '17 at 20:23
  • $\begingroup$ @amoeba I think as the info tag is written, robust-standard-error could be an umbrella for both sandwich and neweywest, but they are not synonyms as I see it. Of the three, I do see sandwich and RSE often used interchangeably, but it seems Newey West is specifically intended for time-series so not a general approach, but a tool for a specific kind of data analysis. $\endgroup$ – AdamO Jan 30 '17 at 21:33
  • 1
    $\begingroup$ @Andy, I don't clearly grasp which tags you think we should retain & which should be made synonyms of which. Would your concern about clustered-SEs be allayed by making it a synonym? (Ie, people would type "clustered-standard-errors", it would be displayed in the tags, but then would be silently changed when they hit submit.) $\endgroup$ – gung - Reinstate Monica♦ Feb 5 '17 at 17:51
  • 1
    $\begingroup$ Ok sorry, I might not have expressed this very clearly. I think that [sandwich] and [neweywest] should be merged into [robust-standard-errors]. The [clustered-standard-errors] tag I would like to keep given the high demand for this tag and its wider applicability. Your idea of making it a synonym of [robust-standard-errors] would probably also work well though. $\endgroup$ – Andy Feb 5 '17 at 18:10
  • 1
    $\begingroup$ @amoeba thanks for your reply. I think also merging clustered-standard-errors into robust-standard-errors would be okay but personally I would prefer if we didn't do it because there seems to be demand for this tag (79 questions). It depends how narrowly we want to define our tag system. In this sense, we could equally move [regressions], [2sls], [logit], [probit] into [estimation]. So I think we should still differentiate a little where this makes sense. $\endgroup$ – Andy Feb 5 '17 at 23:53
  • 1
    $\begingroup$ It would have helped to have this moved to a separate thread. Main considerations: (1) Newey-West standard errors are a special type of "robust" standard errors for time series; (2) as @Andy (I think) reminded, not all of the "robust" standard errors are analytical (e.g., bootstrap), although all analytical "robust" standard errors have the sandwich form (after Huber 1967); (3) clustered standard errors are a special type of a sandwich-type estimator / "robust" standard errors that deal with cluster/spatial/sampling correlation. 1/# $\endgroup$ – StasK Feb 8 '17 at 18:08
  • 1
    $\begingroup$ ... continued: (0) "robust" standard errors are all designed to fix the inverse information matrix var-cov estimate that is sensitive to the model assumption (such as i.i.d. and normality); most of the corrections are originally offered for the linear regression model, and later eventually extended to GLM-type models; (4) a somewhat restricted use of the "robust" standard errors in econometrics literature is indeed in reference to White (1980) standard errors that correct only for possible heteroskedasticity of residuals in linear regression models. 2/# $\endgroup$ – StasK Feb 8 '17 at 18:15
  • 1
    $\begingroup$ There are indeed terminological differences between the different disciplines that utilize these estimators. Econometricians call them "robust" (after robust option in Stata and package in R); I hate this term because these standard errors are not robust in the Swiss sense of the word to the outliers at infinity. Biostatisticians seem to be using "sandwich" more often in the GEE tradition, although I am less familiar with that literature. Survey statisticians have also been utilizing the same algebra, but refer to these standard errors as Taylor series linearization (Binder 1984) 3/# $\endgroup$ – StasK Feb 8 '17 at 18:18
  • 2
    $\begingroup$ @StasK Thanks a lot for this overview, I personally have learnt a lot. I tried googling but e.g. relevant Wikipedia pages are nowhere close to this clarity. My personal impression, based on what you said, is that all of that should be synonymized together under robSE. If terminology differs and topic intertwine, it's more helpful to have everything under one tag so that people could navigate the whole body of these questions. $\endgroup$ – amoeba says Reinstate Monica Feb 8 '17 at 18:29
  • 1
    $\begingroup$ @StasK I think the decision should primarily depend on what will help organizing existing threads better. I.e. I don't see how navigating [sandwich] tag alone will help anybody. But one could probably argue that other three tags are fine as they are... My point is merely that given that we have only 165 Qs with any of these four tags, combining them would not be too excessive. $\endgroup$ – amoeba says Reinstate Monica Feb 8 '17 at 18:41
  • 2
    $\begingroup$ @StasK, questions that would only pertain to R's sandwich package would be off topic. Generally, we're hesitant to have tags whose existence leads people to believe that software / code questions are appropriate. A question about sandwich estimators & the package should be fine, but I'd think someone would just have a subject matter tag & the r tag. For the most part, I see getting the tags right as a way to ensure the information on the site is well organized. Ie, I think it's OK if the tags aren't perfect, but are likely to be better used by unfamiliar people & make info findable. $\endgroup$ – gung - Reinstate Monica♦ Oct 29 '18 at 16:54
3
$\begingroup$

I wonder if there is a difference between the notions of feature construction and feature engineering and therefore whether the two corresponding tags and should not be merged / made synonyms of each other. Judging from the titles and the tag excerpts (there are no tag Wikis), they seem quite similar to me.

  • [feature-construction] has 375 threads, an excerpt, but no wiki
  • [feature-engineering] has 126 threads, an excerpt, but no wiki
$\endgroup$
  • 1
    $\begingroup$ Engineering seems more general, but construction is more highly used. Do you have any thoughts? It would be interesting to see what some of the top users think. $\endgroup$ – gung - Reinstate Monica♦ Jun 3 at 11:33
  • 1
    $\begingroup$ @gung Indeed, it would be interesting to hear those who are active in the tag. My main thought is that one of the two tags might be enough. Feature engineering is not only more general but also gives 4x as many hits as feature construction on Google, so I guess I would favour the former. $\endgroup$ – Richard Hardy Jun 3 at 11:46
1
$\begingroup$

Do we really need two tags for [parametric] and [nonparametric]? I propose that we have a single tag that covers both. Given that existing usage has favored np, we could make that the master, but also update the excerpt / usage guidance and full wiki. Updated suggestion: We create a new tag and map both of the original tags to it. To wit:

$\rightarrow$ $\leftarrow$

  • [nonparametric] 1,290 threads, an excerpt & wiki
  • [parametric] 252 threads (of which 95 have both), an excerpt, but no wiki

The current excerpts are, [nonparametric]:

Procedures that rely on relatively few assumptions about underlying probability distributions.

[parametric]:

Statistical models described by a finite number of real-valued parameters. Often used in contrast to non-parametric statistics.

I'm certainly open to discussion about the new excerpt / usage guidance, but the kind of thing I have in mind might be:

Use this tag to ask about the nature of nonparametric or parametric methods, or the difference between the two. Nonparametric methods generally rely on few assumptions about the underlying distributions, whereas parametric methods make assumptions that allow data to be described by a small number of parameters.

Note that this excerpt has 312 characters, which is longer than the typical excerpt, but well within the limits, and would not be the longest excerpt, even among the top tags.

$\endgroup$
  • $\begingroup$ If there is no substantive disagreement, I'll implement this in a week (4/12/19). $\endgroup$ – gung - Reinstate Monica♦ Apr 5 at 17:06
  • 3
    $\begingroup$ How about mapping both to [parametric-nonparametric]? Too cumbersome? $\endgroup$ – amoeba says Reinstate Monica Apr 5 at 18:51
  • $\begingroup$ @amoeba, I have updated the suggestion. $\endgroup$ – gung - Reinstate Monica♦ Apr 8 at 14:27
  • 1
    $\begingroup$ I like the [nonparametric] tag. This change worries me that I will end up with unhelpful suggestions. To that extent, looking at the [parametric] tagged questions as they stands seems that the use of the [parametric] tag is pretty random. $\endgroup$ – usεr11852 says Reinstate Monic Apr 27 at 22:59
  • $\begingroup$ @usεr11852, what is your suggestion, just get rid of p? $\endgroup$ – gung - Reinstate Monica♦ Apr 28 at 16:52
  • $\begingroup$ I am uncertain that we must change something, why is leaving things as it is a problem? np works fine, and OK, p is a bit a mess but the merge won't fix that. $\endgroup$ – usεr11852 says Reinstate Monic Apr 28 at 16:55
  • 1
    $\begingroup$ @usεr11852, because the questions are ultimately on the same topic, but split up into different tags. There seem to be few threads under p that are about anything other than the distinction b/t p & np, & those that aren't about that don't really form a coherent grouping. So instead of the tags helping to organize the information on the site, they are preventing the information from being well organized. $\endgroup$ – gung - Reinstate Monica♦ Apr 29 at 0:55
  • $\begingroup$ I do not think they are. They are on the same topic if the question is for choosing between a parametric or a non-parametric model. If the question is specific to a non-parametric technique, then they are simply are not on the same topic. I agree that p questions are mostly either "incoherent" or aim to distinguish between np and p but the questions in np are mostly OK so I cannot see how this won't hurt np. $\endgroup$ – usεr11852 says Reinstate Monic Apr 29 at 8:37
  • $\begingroup$ @usεr11852, that's what I mean by on the same topic. The np are largely about the distinction b/t p & np, or about choosing between them, & so are most of the p threads. There are also a large chunk of np threads that are strictly about np (not the difference), & there are an incoherent mish-mash of p threads. Thus, we retag those threads on ideosyncratic topics, then merge the threads on the difference b/t p & np (that are tagged p) into the bulk of such threads (which are tagged np). $\endgroup$ – gung - Reinstate Monica♦ Apr 29 at 13:31
  • $\begingroup$ 1 possibility would be to have 2 tags, np & p-np, for Qs about np strictly vs the distinction b/t the 2. This makes organizational sense in the abstract, but in actual usage, I think it would work worse than just having 1 tag b/c I doubt the modal user would be sophisticated enough statistically or savvy enough w/ the SE system to use a more complicated scheme correctly. Thus, we'd end up w/ less well organized. I think a simpler scheme that groups the related threads together is likely to work best in practice. I'm open to just having np or to just having p-np whichever people prefer. $\endgroup$ – gung - Reinstate Monica♦ Apr 29 at 13:37
  • 2
    $\begingroup$ I don't think we need [p] tag at all, to be honest, it's just a mish-mash. So one option would be to go through the entirety of [p] Qs, and remove it from everything that is not about parameteric vs non-parameteric. Afterwards, merge [p] into [np]. After that, delete the synonym mapping, eliminating [p] entirely. If I understood @usεr11852 correctly, they would be fine with this, but I am not sure how much work would that be and if anybody is willing to do it. $\endgroup$ – amoeba says Reinstate Monica Apr 30 at 9:09
  • $\begingroup$ @amoeba: Agreed. $\endgroup$ – usεr11852 says Reinstate Monic Apr 30 at 10:25
  • $\begingroup$ @amoeba, that's essentially what I had initially suggested. I'm also fine w/ creating a new tag [p-np], that ends up housing both. Basically, I think we're better off getting rid of p 1 way or another. $\endgroup$ – gung - Reinstate Monica♦ Apr 30 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .