Neatly phrased: Trends which appear in slices of data may disappear or reverse when the groups are combined.
Or perhaps even more succinctly: slicing data can introduce bias.
This is less accurate, because not slicing data can also lead to bias.
Simpson’s Paradox (2016)
41–50 of 84 posts
Re: Simpson’s Paradox (2016)
#42Cool article. My knowledge of statistics is really rusty, but isn't this another way approaching the topic of "Bayesian Thinking"? If you think about the scenarios in the article from the standpoint of predicting any given outcome in advance, male vs. female and hard department vs. easy department should be treated as "priors". Or to put it another way, Bayesian thinking means asking the question "What is the chance of X happening given Y?"
A nice intro to the topic: https://betterexplained.com/articles/an-intuitive-and-short-...
Which explains why a positive test on a mammogram means you only have an 8% chance of having breast cancer:
>The chance of getting a real, positive result is .008. The chance of getting any type of positive result is the chance of a true positive plus the chance of a false positive (.008 + 0.09504 = .10304).
>So, our chance of cancer is .008/.10304 = 0.0776, or about 7.8%.
>Interesting — a positive mammogram only means you have a 7.8% chance of cancer, rather than 80% (the supposed accuracy of the test). It might seem strange at first but it makes sense: the test gives a false positive 9.6% of the time (quite high), so there will be many false positives in a given population. For a rare disease, most of the positive test results will be wrong.
Re: Simpson’s Paradox (2016)
#43Earlier quoted context omitted.
Another reason to put the year is it helps people decide if they’ve read it before.
I doubt that helps. For instance, this is from 2016, had you read it before? I’m simply suggesting it because I don’t think it adds anything to the conversation. In addition, I’ve seen this being added more often lately and I worry it makes people think it’s date relevant (as I did) or that it somehow provides less value due to some time delay.
Another reason is it’s possible the same author writes an update or new article on the same topic. The year helps disambiguate that.
Re: Simpson’s Paradox (2016)
#44Simpson's Paradox is one of the many phenomena that shows how different applied ML is from regular software engineering. Another one is feedback loops between decomposed subproblems. In ML encapsulation, shielding away of inner details often does not work. One needs to know what is happening on the other side of the abstraction boundary. This is a problem for managers and PM coning to ML from a purely software engine…
You’re right about ML. But you’re mistaken about software engineering—though in good company with most software engineers.
Of denotation, cache access, confidentiality, authentication, integrity, non-repudiability, performance, thread safety, memory overhead—only denotation and some parts of memory overhead allow composition of abstractions.
Re: Simpson’s Paradox (2016)
#45Observation #2: the paradox is essentially describing statistical gerrymandering. :)
Re: Simpson’s Paradox (2016)
#46Re: Simpson’s Paradox (2016)
#47I'd like to say that the author has been reading The Book of Why , but it seems that he hasn't because he missed the punch line of the section on the paradox: you need a causal model to separate the two branches of the paradox. It's as easy to construct examples where the overall view is correct as it is so construct examples where the separate views are.
I'm unclear: what was the incorrect claim you're saying the author made?
Re: Simpson’s Paradox (2016)
#48Simpson's Paradox is one of the many phenomena that shows how different applied ML is from regular software engineering. Another one is feedback loops between decomposed subproblems. In ML encapsulation, shielding away of inner details often does not work. One needs to know what is happening on the other side of the abstraction boundary. This is a problem for managers and PM coning to ML from a purely software engine…
You’re right about ML. But you’re mistaken about software engineering—though in good company with most software engineers. Of denotation, cache access, confidentiality, authentication, integrity, non-repudiability, performance, thread safety, memory overhead—only denotation and some parts of memory overhead allow composition of abstractions.
Would you mind elaborating on this?
Re: Simpson’s Paradox (2016)
#49Earlier quoted context omitted.
“Just” This would be like saying “it’s just that we haven’t proven P!=NP” in CS. Best of luck. Meanwhile applied people will deal with the problem by model diagnostics and sensitivity analysis as has been done for decades. I can’t wait for the next AI winter to come. So tired of this handwaving by people who don’t seem to have practical experience.
Whoah! You have quite a treasure trove in your favorites. The possibility of getting some work done vanished as soon as I found that.
Always happy to be a bad influence.
Re: Simpson’s Paradox (2016)
#50The sex-discrimination lawsuit against UC Berkley seems to be a kind of academic urban myth; the administration was apparently afraid of such a lawsuit and the study was done in response to those administrative fears.