Tupper's Self-Referential Formula (copied from Wikipedia)

Tupper's self-referential formula is a formula defined by Jeff Tupper that, when graphed in two dimensions at a very specific location in the plane, can be "programmed" to visually reproduce the formula itself. It is used in various math and computer science courses as an exercise in graphing formulae.

Where is the floor function.

Let k be the following 543-digit number: 960939379918958884971672962127852754715004339660129306651505519271702802395266424689642842174350718121267153782770623355993237280874144307891325963941337723487857735749823926629715517173716995165232890538221612403238855866184013235585136048828693337902491454229288667081096184496091705183454067827731551705405381627380967602565625016981482083418783163849115590225610003652351370343874461848378737238198224849863465033159410054974700593138339226497249461751545728366702369745461014655997933798537483143786841806593422227898388722980000748404719

If one graphs the set of points (x, y) in 0 <= x < 106 and k <= y < k + 17 satisfying the inequality given above, the resulting graph looks like this (note that the axes in this plot have been reversed, otherwise the picture comes out upside-down):

So what?

The interesting thing about this formula is that it can be used to graph any possible black and white 106x17 image. Now, actually searching through to search would be extremely tedious, so there's a way to figure out the k-value where your image appears. The process is fairly simple:

1. Start from the bottom pixel of the first column of your image.
2. If the pixel is white, a 0 will be appended to the k-value. If it is black, append a 1.
3. Move up the column, repeating step 2.
4. Once at the end of the column, move to the next column and start from the bottom, following the same process.
5. After each pixel is analyzed, convert this binary string to decimal, and multiply by 17 to get the k-value.

What's my job?

Your job is to create a program which can take in any 106x17 image, and output its corresponding k-value. You can make the following assumptions:

1. All images will be exactly 106x17
2. All images will only contain black (#000000) or white (#FFFFFF) pixels, nothing in between.

There's a few rules, too:

1. Output is simply the k-value. It must be in the proper base, but can be in any format.
2. Images must be read from either a PNG or PPM.
3. No standard loopholes.

Test Images

[ ] should produce ~1.4946x10542

[ ] should produce ~7.2355x10159

[ ] should produce 21801 * 17

[ ] should produce (21802-1) * 17

Check out this Gist for the exact solutions.

This is , so least number of bytes wins.

Wikipedia

Wolfram Mathworld

• Can I take in a PPM? – Maltysen Jun 16 '15 at 20:36
• EDIT: Yes, PPM format is allowed. When I came up with the program I intended for PNGs to be used, but allowing PPM should allow for more golfing languages to participate. – Kade Jun 16 '15 at 20:46
• As I was reading this question, before getting to "What's my job" part, I was positive I'm going to see the word quine somewhere. – Jacob Jun 17 '15 at 12:21
• I won't pretend to be a programmer who can do this kind of stuff, instead I will simply present an innocent, earnest question: Yes, but can it be done in reverse? I.e. feeding in the solution and seeing the *.png generated as the result? – user41644 Jun 17 '15 at 21:06
• @NotAsSharpAsYouGuys: if you have arbitrary precision arithmetic it's trivial, you just have to check the result of that formula for each pixel and output the resulting image. – Matteo Italia Jun 18 '15 at 11:31

CJam, 16

l,l~q:~f*/W%ze_b


With big thanks to Dennis. Try it online

In case you're having problems with the url, this is the input I tested:

P1
106 17
0000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000011111100000000000000000000000
0000000000000000000000000000000000000000000000000000000000000111111000
0000011111100110000000000000000000000000000000000000000000000000000000
0000000000000000000000000110011111100000100111100001000000000000001100
0110000000000000000000000000000000000000000000000000000000001000011110
0100010011111100001000000000000100101001110000000000000000000000000000
0011000000000000000000000100001111110010010110000110001000000000000100
0110010010000000011000000000000000000100100000000000000000000100011000
0110101111000000111111000000000001000110010011111100100100111001111100
0111001011110000000000000011111100000011111111000000110111000000000001
0000100111100000110000110001100000101000001100001000000000000011101100
0000111110110000001000010000000000010010000100100110011001100100100110
0100110010011001000000000000100001000000110110011000011000010000000000
0100110001001001100110011000001001100100110010011001000000000000100001
1000011001100111111111001100000000000100110001001001100110011001111001
1001001100100110010000000000001100111111111001101111111111111100000000
0001001010010010011001100101000110011001100000110000100000000000001111
1111111111010111001001001110000000000000110001101101100110011000111001
1001100111110011110000000000000001110010010011100010001001000100000000
0000000000000000000000000000000000000000000000000000000000000000000000
1000100100010000100000000001000000000000000000000000000000000000000000
0000000000000000000000000000000000001000000000010000010000000010000000
0000000000000000000000000000000000000000000000000000000000000000000000
0001000000001000000011111111000000000000000000000000000000000000000000
0000000000000000000000000000000000000000111111110000


I used the format that GIMP generated when exporting as ASCII pbm, with the comment removed.

Explanation:

l,    read the first line ("P1" magic number) and get its length (2)
l~    read and evaluate the second line (106 17)
q     read the rest of the input (actual pixels)
:~    evaluate each character ('0' -> 0, '1' -> 1, newline -> nothing)
f*    multiply each number by 17
/     split into rows of length 106
W%    reverse the order of the rows
z     transpose
e_    flatten (effectively, concatenate the lines)
now we have all the pixels in the desired order, as 0 and 17
b     convert from base 2 "digits" to a number

• I got it in the URL for you. – mbomb007 Jun 17 '15 at 17:17
• @mbomb007 thanks, not sure what went wrong. – aditsu quit because SE is EVIL Jun 17 '15 at 17:52
• If you don't have to deal with comments, l;l~\qN-/W%zs:~2b* should work just as well. – Dennis Jun 17 '15 at 19:03
• @Dennis OMG, there are several levels of brilliance there :) wanna post it by yourself? – aditsu quit because SE is EVIL Jun 17 '15 at 19:27
• I don't think a separate answer would be sufficiently different from yours. – Dennis Jun 17 '15 at 19:32

Pyth - 21 bytes

Simple to do with pyth's i base conversion. Takes input as PBM file name and reads using ' command. I had to use !M to negate blacks and whites. Everything else is self-explanatory.

*J17i!MsC_cJrstt.z7 2


Try it here online. (Web interpreter can't read files, so is modified and takes file as input).

• I don't think anything in Pyth is self-explanatory. :/ – Alex A. Jun 16 '15 at 23:59
• No language I know can beat this one. But then again none of the languages I know are "made-for-golfing". – Mahesh Jun 17 '15 at 9:10
• Can't open link, path is too long, dang (Safari 8.1) – Kametrixom Jun 17 '15 at 9:32
• Your example image seems wrong. Did you mean to use P2 rather than P3? – aditsu quit because SE is EVIL Jun 17 '15 at 16:07
• Oh wait, it's not even P2, it looks like P1 but inverted – aditsu quit because SE is EVIL Jun 17 '15 at 16:20

Python 2: 133 110 bytes

A first attempt in python using PIL:

from PIL.Image import*
a=k=0
while a<1802:k=(j[a/17,16-a%17][0]<1)+k*2;a+=1
print k*17


• as you only use once Image.open(input()).load and it doesn't looke like you're modifying it, wouldn't it be better to use it as it is, instead of using a var j? it would be something like this from PIL import Image k=0 for a in range(1802):y=a%17;x=a/17;k=(0 if Image.open(input()).load()[x,16-y][0]else 1)+k*2 print k*17 – Katenkyo Jun 17 '15 at 11:50
• Continuing on @Katenkyo's point, you can also just plug in a/17 and a%17 in the appropriate locations, and you can abuse the fact that 1 is truthy and 0 is falsy. Here's the result of these changes, you'll be down to 111 bytes :) – Kade Jun 17 '15 at 13:08
• @Kateyenko, sadly input() gets called on every iteration of the loop with that modification. Editing with other tips though, thank you. – joc Jun 17 '15 at 17:01
• (...<1) --> 0**... maybe? – Sp3000 Jun 17 '15 at 17:28

C#, 199

This was fun! There's nothing wrong with reloading a bitmap 106 * 17 times, right? I did it as a function to save some bytes, not sure if that's legal.

BigInteger s(string i){return (Enumerable.Range(0,106).SelectMany(x=>Enumerable.Range(0,17).Select(y=>new BigInteger(new Bitmap(i).GetPixel(x,y).B==0?1:0)).Reverse()).Aggregate((x,y)=>(x<<1)+y)*17);}


i is the input file name.

Also, as a single expression, just because it is one expression, with i provided or subbed (167 bytes)

(Enumerable.Range(0,106).SelectMany(x=>Enumerable.Range(0,17).Select(y=>new BigInteger(new Bitmap(i).GetPixel(x,y).B==0?1:0)).Reverse()).Aggregate((x,y)=>(x<<1)+y)*17)

• The question says "your job is to create a program..." – Sean Latham Jun 18 '15 at 12:39

Mathematica 69 Bytes

17*FromDigits[1-Flatten[Reverse/@Transpose[ImageData@Binarize@#]],2]&


The Binarize@ can be left out if the image is monochrome format.

This function will reproduce the image:

   ArrayPlot[Table[Boole[1/2<Floor[Mod[Floor[y/17]2^(-17Floor[x]-Mod[Abs[y],17]),2]]],{y,1+#,17+#},{x,106,1,-1}]]&