Code is incompressible. Optimally efficient compiled code cannot be described in fewer bits than the code itself occupies.
(The fact that we write code in highly compressible text form is a concession to human language-processing facilities. Humans wrote code in pure binary form well before we invented more convenient programming languages for doing it in.)
(The compiled binary for your Web browser is almost certainly compressible, by about a factor of two to one. This is in part because it contains lots of text in natural languages, which are very compressible; and in part because it is not optimally efficiently compiled. Compilers can be tuned to optimize for speed or for space; you can guess which we usually use.)
The notion of “sensory modality”, or of senses at all, ultimately implies compressibility. For human survival purposes, the natural world is relatively compressible. I don’t need all the bits that describe the ground or the wall to know that they are solid, opaque, and have other relatively simple but useful properties. I don’t need all the bits about a tiger to respond to it as a dangerous animal. However, a single bit astray in a piece of code can mean the difference between something that runs and something that crashes … or that lets the bad guys take over your machine and use it to tile the solar system with Viagra spam.
So I am unconvinced that a “sensory modality for code” can exist, except insofar as this simply means a superior ability to reason logically and mathematically: to understand code qua code, not as the subject of the sort of compression and approximation involved in human (or robot) senses.
My interpretation is that is how he is defining “optimally efficient”- code that cannot be described in fewer bits than itself.
What—by the same machine it is being run on? That’s a pretty strange way to use the term “efficient”—and not a very portable way to measure how compressible code is.
This sort of processing shouldn’t be thought of as compression. Like a visual system that let’s the AI “sense” the object coordinates in a video feed, the stuff done by a sensory modality for code would just throw away most of the information.
This sort of processing shouldn’t be thought of as compression. Like a visual system that let’s the AI “sense” the object coordinates in a video feed, the stuff done by a sensory modality for code would just throw away most of the information.
True. This is a sort of lossy compression. Or several layers of lossy compression if we want the AI to be able to look at different levels of structure. But lossy compression is the huge space of everything that throws away some information and reduces message size—I think it takes more work to find the stuff we want within that space than it takes to note that we want lossy compression.
And considered as compression, even lossy compression (or co-compression with the AI’s source code, or any such guff), a sensory modality is probably suboptimal, because it has to serve other purposes like making it convenient for the AI to think about code.
Visual systems — and other aspects of our cognition about physical objects — exploit the fact that physical objects are highly redundant.
For my purposes as a human, every square foot of a house wall is pretty much identical to every other square foot of it. One piece of wallboard is pretty much the same as any other, and minuscule differences are irrelevant: removing an atom or a crystal from the wallboard will not alter it much. So it is safe, both physically and epistemologically, to visually encode a whole wall as a bounded surface of a single color, material, and texture, rather than as a huge number of tiny individual constituent particles. There are of course many differences between one square foot of wall and the next, but those discrepancies are highly unlikely to be of any particular consequence.
The same is not true for code. Code is not highly redundant. One kilobyte of code is not pretty much the same as any other kilobyte of code; and minuscule differences are significant: altering a single bit can completely change the outcome of running the code. (Indeed, programmers try hard to reduce the redundancy of code; introducing redundancy into code is “cut & paste programming” which is considered a very bad practice.) Tiny differences in code are of substantial consequence.
With physical objects, most of the atomic-level details cancel out. With code, all of the bit-level details matter.
I like the example Oscar handed me: the sieve of Eratosthenes can be “compressed” as “a program that finds primes.”
The bit-level details matter to a CPU. A human given the instruction “write a program that finds prime numbers” wouldn’t start with bit 1 and then go to bit 2 and bit 3. They would start with high-level structure, maybe a key algorithm, and then move to fine details to make the high-level structure work. Another human looking at the code would be able to see this structure, see the key algorithm, and probably wouldn’t remember all the fine details.
A human given the instruction “write a program that finds prime numbers” must use their background knowledge of prime numbers and algorithms to derive the sieve of Eratosthenes or an equivalent algorithm.
You can study a piece of code, discern that it is an algorithm for finding primes, and label it as such. However, to glance at a new piece of code and recognize it as prime-finding code, rather than defective prime-finding code, requires close inspection and not compression. This does not lend itself to the kind of optimizations suggested by the expression “sensory modality”, i.e. analogy to human sensory processing which compresses away lots of details — even relevant details, which is why we have optical illusions, etc.
That sort of thing is quickly checkable, though—the trouble is if looks like it finds primes, does something else, and that something else isn’t one of the hypotheses generated. Which could definitely make this much less useful if it was common.
I dunno, maybe you’re right and a holistic approach is necessary. But I feel like I understand code modularly rather than holistically, and though I sometimes lose track of details I’m usually pretty good at knowing which ones will be important later.
It’s easy to understand code modularly when it was written straightforwardly. It’s a lot harder when it’s spaghetti code … or when it’s actually intentionally tricky. Past a certain point there’s no choice but to actually step through each possible branch of the code — which can be done, but it’s hardly the sort of automatic layers of approximation and pattern-matching that our senses use.
Someone linked me to the 2008 contest once. I’m more familiar with the Obfuscated C Contest, which would also be a problem. But I think it’s fine to only be able to “intuit” about straightfoward-ish code. The main use, after all, would be to understand code written by your own programmers in order to self-improve.
Code is incompressible. Optimally efficient compiled code cannot be described in fewer bits than the code itself occupies.
(The fact that we write code in highly compressible text form is a concession to human language-processing facilities. Humans wrote code in pure binary form well before we invented more convenient programming languages for doing it in.)
(The compiled binary for your Web browser is almost certainly compressible, by about a factor of two to one. This is in part because it contains lots of text in natural languages, which are very compressible; and in part because it is not optimally efficiently compiled. Compilers can be tuned to optimize for speed or for space; you can guess which we usually use.)
The notion of “sensory modality”, or of senses at all, ultimately implies compressibility. For human survival purposes, the natural world is relatively compressible. I don’t need all the bits that describe the ground or the wall to know that they are solid, opaque, and have other relatively simple but useful properties. I don’t need all the bits about a tiger to respond to it as a dangerous animal. However, a single bit astray in a piece of code can mean the difference between something that runs and something that crashes … or that lets the bad guys take over your machine and use it to tile the solar system with Viagra spam.
So I am unconvinced that a “sensory modality for code” can exist, except insofar as this simply means a superior ability to reason logically and mathematically: to understand code qua code, not as the subject of the sort of compression and approximation involved in human (or robot) senses.
A dubious claim. Do you have a reference?
My interpretation is that is how he is defining “optimally efficient”- code that cannot be described in fewer bits than itself.
What—by the same machine it is being run on? That’s a pretty strange way to use the term “efficient”—and not a very portable way to measure how compressible code is.
This sort of processing shouldn’t be thought of as compression. Like a visual system that let’s the AI “sense” the object coordinates in a video feed, the stuff done by a sensory modality for code would just throw away most of the information.
That is how “lossy” compression works.
True. This is a sort of lossy compression. Or several layers of lossy compression if we want the AI to be able to look at different levels of structure. But lossy compression is the huge space of everything that throws away some information and reduces message size—I think it takes more work to find the stuff we want within that space than it takes to note that we want lossy compression.
And considered as compression, even lossy compression (or co-compression with the AI’s source code, or any such guff), a sensory modality is probably suboptimal, because it has to serve other purposes like making it convenient for the AI to think about code.
Visual systems — and other aspects of our cognition about physical objects — exploit the fact that physical objects are highly redundant.
For my purposes as a human, every square foot of a house wall is pretty much identical to every other square foot of it. One piece of wallboard is pretty much the same as any other, and minuscule differences are irrelevant: removing an atom or a crystal from the wallboard will not alter it much. So it is safe, both physically and epistemologically, to visually encode a whole wall as a bounded surface of a single color, material, and texture, rather than as a huge number of tiny individual constituent particles. There are of course many differences between one square foot of wall and the next, but those discrepancies are highly unlikely to be of any particular consequence.
The same is not true for code. Code is not highly redundant. One kilobyte of code is not pretty much the same as any other kilobyte of code; and minuscule differences are significant: altering a single bit can completely change the outcome of running the code. (Indeed, programmers try hard to reduce the redundancy of code; introducing redundancy into code is “cut & paste programming” which is considered a very bad practice.) Tiny differences in code are of substantial consequence.
With physical objects, most of the atomic-level details cancel out. With code, all of the bit-level details matter.
I like the example Oscar handed me: the sieve of Eratosthenes can be “compressed” as “a program that finds primes.”
The bit-level details matter to a CPU. A human given the instruction “write a program that finds prime numbers” wouldn’t start with bit 1 and then go to bit 2 and bit 3. They would start with high-level structure, maybe a key algorithm, and then move to fine details to make the high-level structure work. Another human looking at the code would be able to see this structure, see the key algorithm, and probably wouldn’t remember all the fine details.
A human given the instruction “write a program that finds prime numbers” must use their background knowledge of prime numbers and algorithms to derive the sieve of Eratosthenes or an equivalent algorithm.
You can study a piece of code, discern that it is an algorithm for finding primes, and label it as such. However, to glance at a new piece of code and recognize it as prime-finding code, rather than defective prime-finding code, requires close inspection and not compression. This does not lend itself to the kind of optimizations suggested by the expression “sensory modality”, i.e. analogy to human sensory processing which compresses away lots of details — even relevant details, which is why we have optical illusions, etc.
That sort of thing is quickly checkable, though—the trouble is if looks like it finds primes, does something else, and that something else isn’t one of the hypotheses generated. Which could definitely make this much less useful if it was common.
I dunno, maybe you’re right and a holistic approach is necessary. But I feel like I understand code modularly rather than holistically, and though I sometimes lose track of details I’m usually pretty good at knowing which ones will be important later.
Ever hear of the Underhanded C Contest?
It’s easy to understand code modularly when it was written straightforwardly. It’s a lot harder when it’s spaghetti code … or when it’s actually intentionally tricky. Past a certain point there’s no choice but to actually step through each possible branch of the code — which can be done, but it’s hardly the sort of automatic layers of approximation and pattern-matching that our senses use.
Someone linked me to the 2008 contest once. I’m more familiar with the Obfuscated C Contest, which would also be a problem. But I think it’s fine to only be able to “intuit” about straightfoward-ish code. The main use, after all, would be to understand code written by your own programmers in order to self-improve.