5 ms·

The 543 digit number encodes log(10^543, 2)~=1803.8 bits, and the image is 17x106=1802 bits. It's going to be hard to fit it in there.

by psuter 12y ago

colanderman 12y ago
You could do it if you modified the formula to decode a compressed bitmap rather than an uncompressed bitmap. You could probably make the compression as simple as encoding a "font" in the number (or formula)... then it's just an extra indirection to lookup each digit's bitmap.
- danbruc 12y ago
  But some numbers will get larger when compressed. And some here means most of them.
  - colanderman 12y ago
    You're not compressing just any number... you're compressing a number representing a bitmap that's mostly white. That that can be done is not just theoretical... it's done all time time. (Computer files are, after all, just large numbers.)
    - danbruc 12y ago
      You are of course correct, somehow I tricked myself into believing this would require compressing the number for every image into its image. But on a second thought there might still be a tough problem - altering the number will alter the image which will in turn require altering the number again. So the (possibly) hard problem is finding a fixed point which may actually not even exist (for a given formula).
      - colanderman 11y ago
        Ah, but there is a science behind writing such things. They're called quines. Here's one I wrote: http://chris.pacejo.net/postscript/quine.ps http://chris.pacejo.net/postscript/quine.ps The trick is that the part of the number (program) that encodes the image of the number doesn't need to encode the image of itself -- that can merely be created directly from that part of the number. See e.g. the source of (or output of!) the quine I linked. The first half of the program is the "image"; the second half basically just prints the "image" once as it is represented in the source, and again after interpreting it a bit. (In fact this way you don't even need to compress the "image"... the compression comes from the fact that your "program" is roughly just two copies of the same thing.)

The 543 digit number encodes log(10^543, 2)~=1803.8 bits, and the image is 17x106=1802 bits. It's going to be hard to fit it in there.

by psuter 12y ago

The 543 digit number encodes log(10^543, 2)~=1803.8 bits, and the image is 17x106=1802 bits. It's going to be hard to fit it in there.

colanderman 12y ago

You could do it if you modified the formula to decode a compressed bitmap rather than an uncompressed bitmap. You could probably make the compression as simple as encoding a "font" in the number (or formula)... then it's just an extra indirection to lookup each digit's bitmap.

danbruc 12y ago
But some numbers will get larger when compressed. And some here means most of them.
- colanderman 12y ago
  You're not compressing just any number... you're compressing a number representing a bitmap that's mostly white. That that can be done is not just theoretical... it's done all time time. (Computer files are, after all, just large numbers.)
  - danbruc 12y ago
    You are of course correct, somehow I tricked myself into believing this would require compressing the number for every image into its image. But on a second thought there might still be a tough problem - altering the number will alter the image which will in turn require altering the number again. So the (possibly) hard problem is finding a fixed point which may actually not even exist (for a given formula).
    - colanderman 11y ago
      Ah, but there is a science behind writing such things. They're called quines. Here's one I wrote: http://chris.pacejo.net/postscript/quine.ps http://chris.pacejo.net/postscript/quine.ps The trick is that the part of the number (program) that encodes the image of the number doesn't need to encode the image of itself -- that can merely be created directly from that part of the number. See e.g. the source of (or output of!) the quine I linked. The first half of the program is the "image"; the second half basically just prints the "image" once as it is represented in the source, and again after interpreting it a bit. (In fact this way you don't even need to compress the "image"... the compression comes from the fact that your "program" is roughly just two copies of the same thing.)