Did anybody solve this? | Hacker News Reader

Did anybody solve this?

1.61803398874.com

36 pointsjgrahamc21 comments

Spoiler Alert!

The answer is rethingdb. Apparently an ad for rethinkdb.com:

    >>> print "".join((chr((ord(x)-int(y)-ord("a"))%26+ord("a")) for x,y in zip("xfbhlqtlj","61803398874")))
    rethinkdb

You know what's sad? I knew that just from the job description. I'm not sure if that means I've spent far too much time on HN over the years, or if there is a real dearth of startups doing systems-level development.

Read up on the Vigenere cipher on Wikipedia. If you still aren't getting it, reconsider which direction you are shifting the cipher text in accordance with the key. Good luck!

(Or do some social engineering and figure out which db company has a 9 letter name.)

Does anyone here have any idea what they mean about naive C and python solutions? Normally I take 'naive' to mean 'bad but not wrong', but their question seems to imply that one or the other of the 'naive' solutions they have in mind is wrong, and I'm not sure what obvious way there is to write it wrongly in one of the languages and produce different results.

Yes. Use the modulus implementation of the vignere cypher. Then look up how C and python handle modulus.

The latter half of the challenge was much more interesting to me. I'm a C/Python guy but didn't know the subtle language difference here. Additionally, in figuring out the difference, I learned that the C implementation takes almost the same # of characters as the python one..

I like how they changed the text from "In your e-mail, please explain why C and Python solutions to decipher the string above return slightly different results."

they added "naive" and "might" ...

Also, did anyone solve their "canine challenge"? It seems to me that what they're asking for is "tee FILE... > /dev/null", but maybe I'm missing something?

The only problem with `tee' is that it's hard to find it unless you know where to look -- took me some 2 years.

Perhaps the real challenge here is sticking with the team that produces incredible qunatities of code, as they put it, and will rather re-implement tee than find it. I wonder if they implemented own virtual memory with on-demand paging yet ;-)

</snark warning>

Except that if you read the problem statement, you'll see that tee doesn't meet the requirement of 'taking advantage of all available I/O parallelism'. Tee writes to each output file sequentially.

Given that their core business is data-stores that take full advantage of emerging storage technologies (such as flash), this seems like pretty relevant question.

Except that if you do: whatever | tee filea | tee fileb | tee filec | tee filed >/dev/null, you'll get parallelism. This works since tee will write first to stdout, and then to the file you pass it. This may not be "all available" parallelism, but I suspect that it's a decent approximation of "good enough".

I did read the problem statement, but I thought tee was writing to all files in parallel. It's surprising that there seems to be no way to achieve that.

Tee writes in one-thread-per-file level of parallelism; simple experiment:

  $ tee foo.bin bar.bin baz.bin < /dev/zero

writes to all three files `at once' (in small time-slices, actually). Used GNU tee from coreutils-8.10.

Perhaps OP meant several-threads-per-file level of parallelism, where number_threads > number_files?

tee has a simple main loop:

  while not EOF: 
    (synchrounously) read up to BUFSIZE bytes from stdin into buf 
    for each output file: 
      (synchrounously) write buf to file

(source code here: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/tee....)

All of the reads and writes are done through synchronous file apis. I don't see where you are getting one-thread-per-file (or any other kind of parallelism) there.

I am by no means a system programmer (I'd love to learn, no idea where to start), but seeing some sort of either breakdown or a list of implementation challenges to solve this problem would be awesome. I get that the man page describes what it needs to handle, but I don't clearly see every moving piece that this would have to deal with and account for.

I submitted the tee solution as a joke and I got a smiley in response. I was pretty pleased with myself.

Yes. The secret URL is rethinkdb.com The key 61803398874 corresponds with the letter of the alphabet with a as 0. Enjoy!

It also works with a as 7.

.. and did you get bonus marks for recognising the Golden Ratio? Or is that too obvious?

It's not that hard. ROT to the left 61803398874 times. Then re think your answer. ;-)

Sure, I did it by hand. Not sure it was really challenging enough to impress me, though.

Reply on news.ycombinator.com