As I like to say: "I approve of preferential voting, but I prefer Approval Voting" :-)
10,315 karma · joined August 31, 2010
As I like to say: "I approve of preferential voting, but I prefer Approval Voting" :-)
Anyway, I'm writing for the HN audience here, not for general consumption :-)
The correct motto, I submit, is "one person, one candidate, one vote". Approval voting falls directly out of that. Every AV ballot has the same amount of influence over the result as every other, because they're all points on a hypersphere whose center coordinates are all 1/2. That is, they all represent points equally far from the point of indifference.
Approval Voting is much simpler to implement and use than IRV, and much less prone to produce anomalous results. More discussion can be found here: https://electionscience.org/
I think the Marquis de Condorcet got the entire field off on the wrong foot with a conceptual framework in which voting is about expressing preferences between candidates. Voting theorists have tended ever since to think in terms of preferential voting. The result is an unconscious bias to the effect that a voter's evaluations of the candidates tend to be roughly evenly spaced: that the gap between their first choice and their second is roughly equal to that between their second and third, etc. You can hear that bias, for example, in this statement from FairVote.org:
[A]pproval voting [has the] practical flaw of not allowing voters to support a second choice without potentially causing the defeat of their first choice.
It's true in AV that if you vote for two candidates, your ballot contributes equally to the potential victory of either; you don't get to say which you prefer. But calling this a "flaw" assumes that you couldn't be somewhat indifferent between those two candidates, at least relative to the degree of your dislike for the other(s). That assumption is pervasive, albeit implicit, in the arguments I have seen made against AV, and it is indeed nothing but an assumption.
A much better conceptual framework is to imagine an N-cube, where N is the number of candidates, and each voter's position as a point in that cube. Then the problem of designing a voting system becomes that of identifying which corner the mean of the positions of the voters is closest to. In principle a voting system could allow each voter to supply a real number in [0, 1] for each candidate, and we could simply add them up and see which is largest. In practice it makes more sense to quantize the space to some extent. Score Voting gives the voter a set of possible values, e.g., integers in [0, 10]. Approval Voting boils that down to the bare minimum of {0, 1}. (My opinion is that once the electorate is large enough, there is little benefit to allowing more than two choices; the greater quantization noise of AV gets averaged out.)
Armed with that, we can now look back at the preferential systems. Is there a way to interpret a preferential ballot in the N-cube framework? Yes, there is. We cut the unit N-cube up along diagonal hyperplanes; for instance, in 3 dimensions (i.e. for a 3-candidate race), the X=Y plane, the Y=Z plane, and the X=Z plane. This gives us 6 prismatically shaped regions. We compute the barycenter of each — the center of mass, under the assumption of uniform density — and look at their coordinates. These turn out to be permutations of [1/4, 1/2, 3/4] — a linear sequence. In short, what falls out of this exercise is equivalent, modulo linear transformation, to the Borda Count.
So the Borda Count optimizes for the case in which the voters' positions cluster near the barycenters of those regions: where their evaluation of the middle candidate, in a 3-candidate race, is about halfway between those of the other two. If you listen closely to the arguments presented by preferential-voting advocates, you can hear them assuming that this is likely to be the case. But there's no reason it should be, and in practice I haven't observed that it tends to be.
There are actually two problems here. One is the absence of bounds checking. The other, which is related but technically orthogonal, is the hole in the type system: an array is not an object. It's been true since Unix v7 that you can pass or return a struct by value, but you can't pass an array by value unless you wrap it in a struct.
The type system also makes no distinction between a pointer to a single object and a pointer into an array of objects. I've worked on static analysis tools that try to find potential buffer overflows, and this turns out to be a surprisingly big problem. One has to do a global dataflow analysis just to discover which pointer variables could ever point at array elements.
Ref: https://www.theatlantic.com/magazine/archive/2019/06/who-is-...
Seconds ago -- there's one in my carport :-) (A 1993 Toyota MR2; it's mid-engine. The frunk is small, and completely filled by the spare tire and aftermarket stereo amp.)
Exponential growth, in this context, means that the rate of new infections is proportional to the number of existing infections. This cuts both ways: when the number of existing infections is large, the rate of growth is also large -- which is why exponential growth is so dangerous -- but when the existing number is small, the growth rate is also small. If you look at a graph of an exponential curve, there's a long relatively flat region to the left, before the knee in the curve is hit and the thing takes off.
The point is, even though we here in CA started the lockdown relatively early, we've never gotten the case numbers down to a manageable level. I'm not sure why not. Although a lot of us have taken the virus seriously from the beginning, maybe there are still too many who don't. The sad truth is that a lot of people won't believe it until it affects someone they know -- and while it's well under control, that tends not to happen. So it looks like a bad outbreak in a region creates "mental herd immunity", where almost everyone cooperates with the lockdown; places that haven't had such an outbreak don't take it as seriously.
Approval Voting simply allows the voter to vote for or against each candidate independently. (The instruction is to "vote for all candidates you approve of" -- hence the name.) "One person, one vote" becomes "one person, one candidate, one vote".
Instant-Runoff Voting (aka Ranked-Choice Voting, though there are other ranked-choice systems) is getting more buzz these days than Approval Voting, but AV is superior: much simpler to implement, easier to understand, and much less likely to return an anomalous result.
For more info: https://www.electionscience.org/
I've also read that in the 1918 Spanish Flu pandemic, the cities with the most stringent lockdowns were the ones whose economies recovered the fastest -- so your model has some empirical support.
I don't think anyone thought of it as established fact. But it also wasn't an established fact that we didn't have to take all those measures. It's a question of risk, not of absolute foreknowledge.
Also, as @acqq correctly points out, a period of time with strict lockdown can reduce the number of cases to the point that a relaxation of controls doesn't immediately result in a large outbreak. An exponential curve has a flat region [0] where it doesn't seem to be getting out of hand. If you manage to put yourselves well into that flat region, you will have bought yourself a period of time in which the controls can be relaxed. But it's only temporary.
Although the site is pretty dead now -- it doesn't have HN's advantage of a wealthy benefactor keeping it ad-free -- its original incarnation had some good ideas.
The fact that the numbers don't seem that dramatic yet doesn't mean that measures to slow the progress of the virus aren't important.
Indeed -- it dates back to the 1920s. At that time, phone numbers in the US started to be formed from a 2-letter exchange code followed by 5 (or sometimes 4) digits. For instance, "PEnnsylvania 6-5000" (dialled 736-5000) was the number of the Hotel Pennsylvania in New York City, and also the title of a 1940 hit song.
Now, a lot of people, when they hear the term "constraints", think of arithmetic inequalities. And indeed, there are "Constraint Logic Programming" extensions to Prolog that support such constraints. But that's not what I'm referring to. Even in the absence of such extensions, Prolog is a constraint language, but the constraints are structural rather than numerical.
Let's take a simple example, the Prolog code that defines list appending:
append([], X, X).
append([X|Y], Z, [X|W]) :- append(Y, Z, W).
This says, first, that 'append' is satisfied if its first argument is empty and the second and third are equal; and secondly, that it's also satisfied if the first and third argument have the same head, and 'append' is satisfied recursively on the tail of the first argument, the second argument, and the tail of the third.Prolog allows any of those arguments to be inputs, and any to be outputs. The way this works is that variables in structures function as named holes to be filled in. So while you can use 'append' as a function to append two lists, like this:
? append([3], [7], X).
X = [3, 7]
you can also use it as a predicate: ? append([3], [7], [4]).
no
Here "no" means Prolog couldn't find any way to satisfy the constraint. Or, you can use it "backwards": ? append(X, [7], [4, 7]).
X = 4
Prolog doesn't even know what's normally an "input" and what's an "output"; it just searches for a solution to the constraints. It can even construct multiple solutions: ? append(X, Y, [4, 7]).
X = [], Y = [4, 7];
X = [4], Y = [7];
X = [4, 7], Y = []
Here's the really powerful part. These solutions are produced one at a time. Some larger goal can be consuming them, such that if it fails, Prolog will try the next one automatically. Thus it's very easy to put together a large, complex constraint and have Prolog search for a solution.The catch, as others have mentioned, is that it does that using a rather naive depth-first search. Even though, at the lowest level, it tries each alternative very quickly, there can easily be a combinatorial explosion of alternatives. To use the language effectively requires the programmer to learn strategies to avoid these explosions. So while in small examples the language seems very declarative, and indeed a lot of code can be written without too much attention to its procedural behavior, eventually this breaks down and you have to think about it procedurally as well.
I was going to say that it probably isn't PET, but a bit of Googling quickly turns up articles about people making houses out of recycled plastic. If that's what it is, it could well be PET.