I think this is a very important area with applications to legal issues; in the computer systems domain, a close application I can think of is troubleshooting / root-cause analysis.
In legal situations and troubleshooting alike, one is often interested not in the "general" causes of why things happen (e.g., an increase in load will contribute an increase in latency), but causes that explain specific cases (e.g., the increase in latency on this incident was because of an increase in file system latency at the backend.)
These concepts are quite interesting; one linked article discusses many variations and refinements in detail: https://plato.stanford.edu/entries/causation-law/. I found these useful mental models to organize my thoughts when troubleshooting systems and doing root-cause analysis:
- But-for cause: We can say that A is the actual cause of B when the following holds: If not for A, not B. To avoid pathologies like "If not for big bang, this B wouldn't have happened", we have ...
- Proximal cause: In the causal chain of explanations: If not for A1, not A2; if not for A2, not A3, ..., the proximal cause of A(k) is the closest, i.e., A(k-1).
- Necessary element of a sufficient set (NESS criterion): Things get interesting here if we need a conjunction of many events to happen simultaneously for a desired effect. For simplicity, assume that events are boolean, and causal relationships can be defined using boolean formulae. Here, A is a cause of B in the NESS sense, when B = (A and C1) OR (C2 and C3) OR ... A here is "necessary" in the sufficient set {A, C1} for B to happen.
Most people have some vague sense that these aspects are important, and would probably come up with a similar taxonomy if pressed, eventually. But getting the details right and using consistent terminology matters; we don't usually notice how woolly our thinking is until we make a real effort to be precise. Think of something like the SemVer standard: "everyone knew" this was what version numbers meant, but writing it out explicitly in a precise way was actually really valuable.
The complexity of defining and determining "actual causality" is a good justification for mathematicians' avoiding the whole thing and using material implication instead. As most of you already know, material implication A -> B ("A implies B") is a boolean operation, which is the same as ((not A) OR B), see https://en.wikipedia.org/wiki/Material_implication_(rule_of_... . Material implication avoids all this complexity.. but because it's simpler, it cannot by itself represent our notions of causality. Material implication even has some "weird" surprises, e.g., "All Martians are green" and "All Martians are not green" are both true when defined using material implication. I created an "allsome" quantifier to deal with this problem: https://dwheeler.com/essays/allsome.html . But it'd be nice to learn about other alternatives, so I started reading this.
I've only started reading this book, but the approach does seem a little odd. Its definition of causality embeds a model, which has embedded causality in it. In section 2.1 https://www.cs.cornell.edu/home/halpern/papers/causalitybook... it notes this issue: "It may seem somewhat circular to use causal models, which clearly already encode causal relationships, to define causality. There is some validity to this concern... Nevertheless, I would claim that this definition is useful."
I don't have a better idea, and I can see the value in making the use of models clear. But it does seem to weaken the idea of defining causality. Is this considered reasonable? Is there a possibly better approach?
Anything by Judea Pearl, but especially the Book of Why[1], is good. He comes at causality from a CS perspective, which I think would make sense for most people on here.
Economists also have a big causality literature which might be less accessible for HN folks but I think is still interesting and important. For a good intro to all that, I suggest Scott Cunningham’s “Causal Inference: The Mixtape.”[2]
Pearls model based causality is from a set up the same as structural econometric models of the economists.
Here, economists largely care about identification and partial identification (check work by Manski), which is at the same time related to causation but also a more practical matter of data and model choice.
I'm familiar with the usual potential outcomes framework, and some of the high level machinery of Pearl's version too, but this 'type causality' vs 'actual causality' mentioned in the intro seems like a very unnecessary complication that just confuses things.
They use "smoking causes lung cancer" as an example of type causality. A counterpart in actual causality would be "Dave's smoking caused him to get lung cancer." Then they go on to talk about how these are such different kinds of causality.
They're no more different than "Dave has $35 in his pocket" and "the average american has $21 in their wallet."
Seems totally unnecessary. Am I missing something?
Perhaps Dave is suing his employer for compensation because he developed cancer after working with material which was later found to be carcinogenic. Dave's employer argues that since Dave was a smoker, his smoking caused his lung cancer, and they are not liable. Dave admits thats smoking causes lung cancer, but argues that it did not cause his lung cancer.
I get that individual treatment effects are useful as well as average treatment effects. I just don't get how how that requires a new conceptual type of causality.
Not surprising, since mutual information is a fundamentally non-causal concept. This is easily seen by nothing that the mutual information of X and Y is the same as the mutual information of Y and X, which means that mutual information can't distinguish between "X causes Y" and "Y causes X".
There are causal accounts that use mutual information and its variants though. A lot of them introduce notions of directed mutual information and other similar concepts.
In legal situations and troubleshooting alike, one is often interested not in the "general" causes of why things happen (e.g., an increase in load will contribute an increase in latency), but causes that explain specific cases (e.g., the increase in latency on this incident was because of an increase in file system latency at the backend.)
These concepts are quite interesting; one linked article discusses many variations and refinements in detail: https://plato.stanford.edu/entries/causation-law/. I found these useful mental models to organize my thoughts when troubleshooting systems and doing root-cause analysis:
- But-for cause: We can say that A is the actual cause of B when the following holds: If not for A, not B. To avoid pathologies like "If not for big bang, this B wouldn't have happened", we have ...
- Proximal cause: In the causal chain of explanations: If not for A1, not A2; if not for A2, not A3, ..., the proximal cause of A(k) is the closest, i.e., A(k-1).
- Necessary element of a sufficient set (NESS criterion): Things get interesting here if we need a conjunction of many events to happen simultaneously for a desired effect. For simplicity, assume that events are boolean, and causal relationships can be defined using boolean formulae. Here, A is a cause of B in the NESS sense, when B = (A and C1) OR (C2 and C3) OR ... A here is "necessary" in the sufficient set {A, C1} for B to happen.