Interview question of the Beast?

by Michael S. Kaplan, published on 2008/01/10 19:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/01/10/7064507.aspx

In the bold tradition of interview questions I might be willing to ask, and inspired by Event code of The Beast from earlier today, as modified by Lionel's comment pointing out the error in Heinlein's book...

The question?

Write a program to provide the exact value of 666, by which I mean not

(6^6)^6, i.e. 10,314,424,798,490,535,546,171,949,056

but instead

6^(6^6), i.e. ?????

Anyone think they can do it?

Extra points if you include the commas.

And extra extra points if you instead do the grouping appropriately from an internationalization standpoint....

Disqualification if you use the Perl trick that does not display so well in the blog admin panel. :-)

The program should try to display the string, and you will not be penalized if the technology you use to display it can't handle such big strings, a long as the code is right and the algorithm is sound. :-)

This post brought to you by ? (U+003f, aka QUESTION MARK and by Grey's Anatomy, which has an all new episode on tonight!)

Rather topitcally for this blog, it could be that 616 and 666 are both the number of the best, depending on which language you are using:

"The difference in numbers has also been explained by the fact that the Greek and Latin spellings of Nero’s name transliterate differently into Hebrew"

(The theory being that 616/666 were codes for "Nero" and the whole thing was about secretly calling Emperor Nero evil. Luckily they used such vague terms that this rubbish has stayed with us to today!)

Hello everyone -- we are looking for an ALGORITHM. If the person who made that work in a programming language was submitting their algorithm, they'd get the job.

But people who can't show the work that they came up with? We have a job for them, cleaning the foyer to the ladies room. :-)

Zooba on 10 Jan 2008 9:49 PM:

Getting my first half of the answer in, still working on the digit grouping.

This is a nasty piece of work, long multiplication based on strings, and could easily be optimised/neatened/improved but I was lazy - this way saves converting it to a string later. The answer matches John's:

I'm resisting the urge to post the full output, since there is little point. Who _really_ cares about 6^(6^6) anyway? :-P

Michael S. Kaplan on 10 Jan 2008 10:29 PM:

Well, technically I cared.... :-)

But note that wanting to use GetNumberFormat for the call here doesn't say what you are going to do ablout the multiple large allocations that this code plus that would require, or the amount of stack space you are using (the kinds of things I ask aboit if you wrote this on my white board).

Lars Viklund on 11 Jan 2008 12:33 AM:

The following solution is in Haskell, supports arbitrary group sizes and delimiters. The algorithm is basically "calculate the number using the Integer type (which is a bignum), split it into a list of Ints, intersperse with the specified delimiter and print it all.

As for possible performance bottlenecks, I'd nominate the recursive functions use of list concatenation (++), but otherwise it shouldn't bloat too much with intermediaries.

module Main where

import Data.List (intercalate)

import Text.Printf

main = putStrLn $ commaFormat (6^6^6 :: Integer) 3 ","

commaFormat x groupSize delimiter =

let (t:ts) = f (10^groupSize) x

fstr = "%0" ++ (show groupSize) ++ "d"

in intercalate delimiter $ show t : map (\y -> printf fstr y) ts

f den x | x < den = [x]

| otherwise = let (q,r) = quotRem x den

in (f den q) ++ (f den r)

Lars Viklund on 11 Jan 2008 2:03 AM:

In the real world though, I would use the best of two worlds and calculate the number in Haskell and make an foreign call to GetNumberFormat instead.

After testing that, it's much faster, slimmer and neater and it puts the burden of formatting the number on something that knows more about the user preferences, namely the OS.

Michael S. Kaplan on 11 Jan 2008 2:19 AM:

First time I've seen a problem solved in Haskell in a while. Cool! :-)

Does that count as calculating in Haskell, though? It looks like it is doing the work since it has a big number type....