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.

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.

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

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.

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

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];
        }
    } 

    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);

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.