frud

I think that, more generally, intelligent people don't get arrested for crimes for several reasons. First, because they are smarter, they just don't get themselves into jams where murdering someone seems like the best way to get out of the jam. Second, because they are more successful they have more to lose in terms of wealth, happiness, good living situation, so they risk more when choosing crime, so they're less likely to choose it. Only thirdly is actual proficiency in the planning and execution of the crime.

The raw words written to the drive are actually re-encoded into slightly larger codewords with nice properties like not having too many zero or one bits in a row, and error detection/correction.

Plus I think that the 0/1 bits are not encoded as "no magnetism"/"some magnetism", but instead as "north magnetism"/"south magnetism" since magnetic fields have a direction.

And I don't think the magnetic fields on the platters have any appreciable effect on the head besides the electromagnetic effects at the sensor.

The game goes through several phase changes as you progress.

Any form that doesn't have loose fibrils, microparticles, or dust.

I'd compare it to wood from walnut trees, which is perfectly safe to handle and use in dining tables, etc., but dust from its' woodworking is toxic.

I used to work for a company that sold factory automation technology, and had hundreds of manuals for all the products they sold. In the front matter of every manual was a disclaimer that nothing in the manual was warranted to be true. This was automation equipment running things like steel mills, factories, petroleum plants, where failures could result in many deaths and grave financial losses.

The real story here is that Air Canada's lawyers argued, among other things, that the chatbot was a separate and independent legal entity from Air Canada and therefore Air Canada was not obligated to honor the made up policy.

In other words, this was possibly the first historical argument made in a court that AI's are sentient and not automated chattel.

For basically forever compilers and languages have been designed with a total ordering on operator precedences. The Yacc compiler generator tool maps operator precedence to integers, as do most handwritten compiler parsers.

A total ordering has a definite answer to the question "is x greater than, equal to, or less than y?" for all x and y. A partial ordering will answer "I don't know" for some x and y.

It's quite possible to implement operator precedence using a partial ordering. When the parser has to resolve precedence between two operators and their relationship is not defined, throw an "ambiguous precedence" error.

You can implement the partial ordering by putting all the operators into a DAG of sets of operators. If two operators are in the same set, they have equal precedence. If there is a path through the DAG from one operator to the other, that defines the precedence relation. Else there is no relation.

Say "*" is defined to have a higher precedence than "+", and they both have an undefined precedence relation with "&". Then "1 + 2 * 3" should compile into "1 + (2*3)", but "1 + 2 & 3" should throw an "ambiguous precedence" syntax error.

Even if it's stable in a game theory sense, it depends on the political class being partitioned into exactly two parties. Otherwise the two biggest parties would have an incentive to smother all smaller competitors.

I think the answer has to lie in an algorithmic solution dependent on a high-resolution population density map.

Fish + fire = sushi

Wow, cool. A paper that costs $20 to read. I'll be sure to hop on that.

That's quite an injection if it can cure six children at once.

I have an idea. Why don't we give new experimental AI systems their own off-grid nuclear power plants so they can't be switched off. There's no way that could go wrong.

Some are made from dissimilar metals. https://www.coin-database.com/series/japan-47-prefectures-co...

After 30 seconds of furious googling: https://developer.nvidia.com/cuda-fortran

One big thing I remember is that it's illegal to have multiple array arguments reference overlapping storage, so storage regions can't alias. This means functions can be optimized more aggressively.

My fingers can't type Fortran anymore, so I'm going to use C as an example.

Imagine you have this function:

    /* Add entries in arg1 to arg2, put result in result */
    void add_vec(int arg1[], int arg2[], int result[], int length) {
        for(int i = 0; i < length; i++) { 
            result[i] = arg1[i] + arg2[i];
        }
    } 

In C, it's perfectly legal to call this like so:

    int array[101];
    // ...pretend array is initialized...
    // for the first 100 elements, set a[i] = a[i] + a[i+1]
    add_vec(array, array+1, array);

The C compiler has no choice but to iterate through the array one element at a time, doing things in the exact order that the source code spells out. No loop unrrolling or vectorization can occur.

In Fortran, the compiler knows that the arrays are not aliased, so it can do much more reordering, unrolling, and vectorization to speed this code up.

Thank you. This is the first thing I've read about this story that is at all coherent.

Quantum or no, there is no shortcut around the 40.66 kJ/mol it takes to evaporate water.

What exactly is the distinction between water vapor and steam?

It takes [40.66 kJ/mol](https://en.wikipedia.org/wiki/Enthalpy_of_vaporization) to vaporize water. There are no shortcuts.

I can't wrap my head around this story. What does it mean in thermodynamic terms? Isn't there a fixed amount of energy per mass that it takes to convert liquid water into vapor? Why does it matter that the energy comes from light?

I can't believe that video games still have a "saving data. Please do not turn off your computer" like two-phase commit hasn't been a thing since 1987.

His method for computing entropy is not so good. His method works for an independent and unpredictable sequence of bytes, but the actual data is a bunch of signed 16-bit residuals that presumably are normally distributed. Really, he should be measuring the entropy of the original heightmap, but instead he is measuring the entropy of the heightmap after he has applied a couple of confounding transformations (predictive filter, words->byte pairs, and a random shuffle) that act to increase the apparent entropy.

Calculating the exact entropy of data is at least as difficult as breaking encryption. Encrypted data should be indistinguishable from random (full-entropy) noise, but really its entropy should be the entropy of the plaintext data plus the entropy of the encryption key.

If you can measure the front and back horizon accurately you can measure the left and right horizons too, and that will give you an accurate down vector.

But I don't think it's possible to measure a horizon that accurately. There are temperature and pressure dependent atmospheric effects at low angles that effect how light refracts and curves through the atmosphere, and these effects will have to be compensated for to measure the angle accurately. Additionally, there are mountains and valleys to compensate for.

A very precise estimation of which direction gravity is pulling down towards. Which is almost, but not exactly, the vector towards the center of the earth. And it also needs to be disentangled from the suborbital centrifugal/centripetal forces experienced by the movement of the Blackbird.

I think that in order to calculate your latitude and longitude position using what amount to high-tech sextant readings you have to know your local down vector to a high degree of accuracy. That is, the system judges the position of the Blackbird by comparing its local down vector with the angles to the star sightings. If the down vector measurement is off by an arcsecond, the measured latitude and longitude position on the earth will also be off by an arcsecond (at sea level, about 600 feet).

It seems to me that there's an interesting problem that the Blackbird goes so fast that its down vector changes dramatically over the course of a typical flight, so I'm wondering how it accurately updates its down vector reference. Jets can go through arbitrary and wobbly 3-d trajectories, accelerating in any direction, so it can't be a simple measurement of gravity. It would have to be a accelerometer combined with inertial and gyro and elevation readings all summed up.

Any scheme that does not make allowance for illegal moves or invalid positions is not suitable for purpose, IMO. In OTB situations players can make mistakes that no one catches. These illegalities become part of the official record of the game.

I wish I knew 1984 better so I could find an apposite quote.

That was nice.

Please correct me if I'm wrong here, I'm not trying to insult anyone or start a war. But this is a scheme working group, right? Is scheme really that important today to so many people? I haven't touched lisp since I stopped using EMACS about 10 years ago. I haven't heard about anything interesting involving lisp (except I've heard of clojure) since even before then.