Perplex City - We Love Puzzles

Also trk was right, LZW compression is the way to go, or some variant. i'm thinking it is a greyscale picture but i know absolutely nothing about this stuff, and i cant program

Converting all those numbers I get an ascii string that looks like "[large number]:[large number](i,j)". My initial reponse is that it's something to do with a public-private key pair, but I'm not sure what for. Is there something else hidden on the card?

the key to the Thirteenth Labour

how did you decode the brackets?

Since the second value in each bracketed pair is a 0 or a 1 (apart from the final -) I've assumed that that value is a literal in the decompressed data and will produce a binary string.

For the first value in each pair I've tried a few different things and this was the first one that produced anything that looks like a sensible binary pattern.

I've tried insertion position from front, insertion position from back, previous repeat reference, front repeat reference, repeat first n instructions, repeat last n instructions and dictionary reference with two different initial dictionaries.

The repeat previous and from front both produce something that could be a bitmap image, but there didn't seem to be any recognisable pattern in the image at any size.

The final dictionary reference I tried produced a binary string with a multiple of 8 digits that when converted to bytes gives a sensible string in the 8-bit ASCII range. This suggests it's the right decode (although it uses both 44,1's, with one as 44,0 it gives either a '%' as one of the chars or a couple of !'s, " and a space, but the string is still mostly the same.

It's good to see the "Data Encoding and Encryption" classes I took 12 years ago are useful

But I dont get it, literally how are you getting from these brackets to an ASCII string?

Ah i get it now, you start with (0,0), then each time you reach a "dead end" you move to the next unvisited bracket. The bracket (a,0) means you record 0 as the next bit in your data then move back to bracket a. Am I right? This would explain why no bracket has an "a-value" that is more than its bracket number

Something like that, there's several schemes that can be used for the "move back to bracket a" bit. You could instead repeat the last a digits and then add the 0 or 1. The scheme I used to get the ASCII was based on LZW and involves a dictionary lookup, i.e. add the dictionary entry for "a" to the output and then the 0 or 1. In LZW type schemes the dictionary grows as new combinations of output symbols are found.

well what marc said keeps bugging me, how the change of that second (44,1) to (44,0) "wouldnt matter" but it correct to avoid repetition. What if when we goto the next bracket we dont record the bit and just do the recursion business? This would fit with what marc said because you never end up using this second (44,1) as there is no number 53 anywhere (which is the position the (44,1) is in, hence later in the string you never have to go back there, the error wouldnt make a difference). Also this would fit with the final bracket which has no bit in it.

a mathematician and cryptographer and has some interesting stuff at http://www.law37.com/about.html

Now ive got an idea what im doing, lol, i'm trying lots of variations on my previous idea, all of which come up with ASCII in the right range for a few letters then end up giving me symbols, etc. Its a pain, there is no hint anywhere on the specifics of the decryption.

I think we can safely say that (0,0) is "one dead end" and then its a fight between (1,1) and (0,1). If we are starting our bracket count at bracket 0, then (0,0) and (1,1) are the dead ends, they give the lone 0 and 1 in the dictionary, but if the bracket count starts at 1 (and 0 is taken to mean stop) then (0,0) and (0,1) are the dead ends.