throw5away

Honestly, this entire post reads like a fever dream.

You don't need the n bits of information from each ballot. You can just transmit the aggregate counts. A human can easily put tally marks in each of n buckets. In fact, a computer would likely do the same instead of creating an exponential number of buckets...

If you insist on a degenerate formulation, just split the ballots into n different elections and transmit the results of each one of those elections. We can use the same equipment we have today.

Do you have something US-specific to indicate that this would be the case? Neither empirics nor theory support your claim. https://rangevoting.org/TarrIrvSumm.html

Nope! This is a problem with high-cardinality ordinal voting methods. Since factorial is a very fast growing function, you can easily encode a pattern in down-ballot candidates and buy and verify a specific ballot.

Commonly what's done is that we truncate the ballot and only allow people to express, say, 5 preferences.

I'd go as far as to say Approval > FPTP > IRV. FPTP has good properties like monotonicity (for a good example see http://zesty.ca/voting/sim/), easily distributed counting, and preservation of the secret ballot that IRV does _not_ have.

You really don't get much bang for your buck by switching to IRV; I'd say it's a negative deal overall.

Honestly IRV is _even worse than plurality_. It doesn't solve the problems it sets out to solve (it entrenches two-party domination [1]), it has ridiculous monotonicity violations [2], all for a lot more complication in counting the votes (you can't distribute the counting well without transmitting the contents of all of the ballots) and possibly wrecking the secret ballot (you can encode and buy specific down-ballot rankings).

Seriously, it's all of the disadvantages and very limited upside.

[1] https://rangevoting.org/TarrIrvSumm.html [2] http://zesty.ca/voting/sim/

If you accidentally write "return x = 1" when x is a variable, you always return true. If you return "1 = x", you cause a syntax error. So some people have gotten into the habit of writing constants on the left, even if the return value of __builtin_popcount is not assignable.

This is essentially equivalent to feeding the input through bitwise-NOT first. Unfortunately, there are far more integers that are neither sparse nor dense than integers that are sparse or dense.

since submissions should link to english content in the first place

I don't think this is the case. I certainly don't see anything like that in the [guidelines](https://news.ycombinator.com/newsguidelines.html)

I had $200k+ TC new grad offers from FAANGs in 2013, and one of them wasn't even for a role in the Bay Area. It's not a stark contrast at all. The market has been consistently willing to pay strongly for new talent.

I generated two random 35 digit primes, multiplied them, and then tossed the product into the first hit for "factor integer online": https://www.alpertron.com.ar/ECM.HTM

1731 322587 637083 705865 442033 654804 904216 446486 784497 444181 466938 498269 (70 digits) = 25317 847509 490819 861309 522806 413689 (35 digits) × 68383 482718 586893 688113 139227 257221 (35 digits) Time elapsed: 0d 0h 0m 23.8s

This is in JavaScript on a single core on my laptop.