= 27d567bc2d48d9f40e9ccc20ea370b15)
jmmcd comments on A note on the description complexity of physical theories - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (177)
Another way to think of the constant-size prefix is that one can choose any computer language in which to write the program which outputs the string, and then encode a compiler for that language in the prefix.
This works fine for theory: after all, K-complexity is not computable, so we really are in the domain of theory here. For practical situations (even stretching the term "practical" to include QM interpretations!), if the length of the prefix is non-negligible compared to the length of the program, then we can get misleading results. (I would love a correction or some help in supporting my intuition here.)
As a result, I think I agree that the choice of representation matters.
However, I don't agree that there is a principled way of choosing the right representation. There is no such thing as the substrate domain. Phrases such as "the essential entities and relationships of the domain" are too subjective.
For the purposes of complexity comparisons the prefix should be held constant across the algorithms. You should always be comparing algorithms in the same language.
You are correct. I only use phrases such as "the essential entities and relationships of the domain" to outline the nature of the problem.
The problem with comparing the complexity of QM interpretations is that our representation of those interpretations is arbitrary. We can only guess at the proper representation of QM. By choosing different representations we could favor one theory or the other as the most simple.
Oh, that seems sensible. It makes the problem of choosing the language even more acute though, since now we can ignore the description length of the compiler itself, meaning that even crazy languages (such as the language which outputs Encyclopedia Brittanica with a single instruction) are in contention. The point of requiring the language to be encoded in the prefix, and its length added to the description length, is to prevent us from "cheating" in this way.
I had always assumed that it was necessary to allow the prefix to vary. Clearly "abcabcabc" and "aaabbbccc" require different prefixes to express them as succinctly as possible. In principle there's no clear distinction between a prefix which encodes an entire new language and a prefix which just sets up a function to take advantage of the regularities of the string.
Yes, and this is important to see. The split between content and context can be made anywhere, but the meaning of the content changes depending on where the split is made.
If you allow the prefix to change then you are considering string lengths in terms of the base language. This language can bias the result in relation to the problem domain that you are actually interested in.
As I said above: