Haskell

My First Yesod App

First off, I just wanted to say that I hope everyone had a relaxing and enjoyable holiday season and that you enjoyed your New Year's celebration. Whatever you did that day or night, don't name it after me.

In my last post, I showed you how to create a simple web service that responded to three different URLs and interacted with a database using Python and the Flask framework. Now I'm going to show you how to program the same thing in Haskell using the Yesod framework. For those of you too “efficient” to look them up on the previous page HERE, I'm going to repost the requirements:
Using python with gevent 0.13.x and your choice of additional libraries and/or frameworks, implement a single HTTP server with API endpoints that provide the following functionalities:

      A Fibonacci endpoint that accepts a number and returns the Fibonacci calculation for that number, and returns result in JSON format. example:

      1. $ curl -s 'http://127.0.0.1:8080/fib/13'
      2. {"response": 233}
      1. $ curl -s 'http://127.0.0.1:8080/fib/12'
      2. {"response": 144}
      An endpoint that fetches the Google homepage and returns the sha1 of the response message-body (HTTP body data).example:

      1. $ curl -s 'http://127.0.0.1:8080/google-body'
      2. {"response": "272cca559ffe719d20ac90adb9fc4e5716479e96"}
      Using some external storage of your choice (can be redis, memcache, sqlite, mysql, etc), provide a means to store and then retrieve a value.Example:

      1. $ curl -d 'value=something' 'http://127.0.0.1:8080/store'
      2. $ curl 'http://127.0.0.1:8080/store'
      3. {"response": "something"}</li>

Like the last post, I'm going to talk about the individual functions first, then post the whole code at the end. Let's start with the first requirement, creating a good old Fibonacci sequence:

  1. handleFibR :: Int -> Handler RepJson
  2. handleFibR num = jsonToRepJson $ object ["response" .= show_fib]
  3. where
  4. show_fib = show $ fib num
  5. fib :: Int -> Int
  6. fib 0 = 0
  7. fib 1 = 1
  8. fib n = fib (n - 1) + fib (n – 2)

I'm going to go ahead and describe the code from the bottom up - it's a little weird but it's a lot easier to explain that way, trust me. The show_fib function is just a simple function to sum the values created from the Fibonacci sequence. The result of that function is used as the “value” component of a Pair type that is created with the “.=” operator and the “response” string, and is contained within a list. The object function takes a list of Pairs as its input and creates a Value type, which is described in the documentation as “A JSON value represented as a Haskell value.” This Value is then passed as the input into the jsonToRepJson function. All of these functions come together beautifully so that when you point your browser to http://localhost:3000/fib/24, you get this response:
{"response":"46368"}

For my next trick, I'm going to pull a SHA1 hash out from the Google homepage source code.

  1. gGoogR :: Handler RepJson$
  2. getGoogR = do$
  3. body <- try (simpleHttp "http://www.google.com”)
  4. case body of$
  5. Left (SomeException ex) -> jsonToRepJson $ object [“response” .= (“ERROR: “ ++ (show ex))]
  6. Right val -> jsonToRepJson $ object [“response” .= (showDigest $ sha1 val)]

Much like the last function, this function will return a Handler containing a RepJson . First I use the simpleHttp function to travel to the interwebs and pull the Google homepage. Because simpleHttp will throw an HttpException with any non 200 status code, I have the function called within a try function, putting the result into “body”. Body is of the Either type, which means it can have one of two possible values (like Schrodinger's cat). If something went wrong, the value would be in the “Left” side of the Either type. If that's what happened, I don't really care what went wrong so I just return a generic error message. If everything flowed smoothly like all code does (snicker), the data would be on the “Right” side of Either, allowing me to pull the data out using the Right function and named val. The code after this point is extremely similar to the previous example, the difference being the output. The website source code is used as input for the sha1 function, creating a Digest type, then I carry that over to showDigest, which returns a string 160 characters long. All of this is bubbled up to the handler and the user sees:

{"response":"ddd27a244477532f7be5207582afca72b9f74224"}

Your results will differ! For dealing with the database, we need functions that can handle both GET and POST requests. Before I explain those functions, I want to take a quick moment to share the database schema and the “runDB” function:

  1. share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persist|
  2. Stuff
  3. value Text
  4. deriving Show
  5. |]
  6.  
  7. runDB action = do
  8. Challenge pool <- getYesod
  9. runSqlPool action pool

If you are a little confused by these two things, don't fear. I will do my best to describe them in a moment. If that still doesn't help then maybe viewing the entire code base below will. The first code block above is responsible for creating the Stuff database which holds a single column, called “value”. It reminds me of user defined datatypes created with the “data” Haskell keyword.

The second block is really me cargo cult programming. I've seen this technique used in a lot of the examples of the Yesod book, so I copied it while I was writing this project. The best way I can describe it is as a wrapper function for using an item from a pool of database connectors, and using some of those connectors to to run the query.

Now that you know what the database looks like and how we access it, we can move onto the functions that interact with it. Here is the code for the POST request:

  1. postStoreR :: Handler ()
  2. postStoreR = do
  3. mvalue <- runInputPost $ ireq textField "value"
  4. runDB $ insert $ Stuff mvalue
  5. sendResponseStatus status200 ()

This function just returns a Handler unit. Using the ireq function, we look through the POST request for the expected input keyed as “value”. The output of that function goes through the runInputPost, and deposits the contents into mvalue. We take mvalue, change it to become a Stuff type, pass that to the insert function which, when it runs, returns an automatically created key. and then moving that along to runDB, which inserts our data into the database. The last line returns the 200 status back to the client, using the sendResponseStatus.

Finally, for the GET request we have:

  1. getStoreR :: Handler RepJson
  2. getStoreR = do
  3. mvalue <- runDB $ selectFirst [] [Desc StuffValue, LimitTo 1]
  4. case mvalue of
  5. Nothing -> jsonToRepJson $ object ["response" .= (show "NO DATA IN DATABASE")]
  6. Just mvalue' -> jsonToRepJson $ object ["response" .= (show . stuffValue $ entityVal mvalue')]

The result of the selectFirst function provides the input for runDB. The first argument for selectFirst is an empty list, this argument is for filtering on some kind of value( greater than, less than, not equal to, etc). I have left it blank because I really don't care what the value of “value” is; I just want it. The second list is telling the database to put the column values in descending order. The first line is the Haskell equivalent of the following SQL code:

SELECT * FROM Stuff GROUP BY VALUE DESC LIMIT 1;

The results of which are named mvalue. Since it's possible to have nothing in the response, I use the case statement to dig inside mvalue and look around. If “Nothing” was returned, I send back a little json blurb letting the user know that nothing was found, most likely because there isn't data in the database. If something was returned, pull that value out, and mix it all in the with json recipe you've seen me using thus far, and then send the data on its way.

As the title says, this was my first Yesod web app. I know that I have only scratched the surface of what this framework can do and I'm really interested in creating more with it. I will admit that I initially found the interaction with the database a little cumbersome when compared to Django or Flask. That doesn't mean I don't like it, it's just a little awkward when I was first trying to understand how to work with it. Once I got over those differences, I realized that it mentally translates to SQL better than the other frameworks. Again, I really like Yesod and look forward to using it in the future.

As always, I and my code welcome questions, comments, and the occasional funny and creative insult.

  1. {-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell #-}
  2. {-# LANGUAGE GADTs,OverloadedStrings,FlexibleContexts, FlexibleInstances #-}
  3.  
  4. import Yesod as Y
  5. import Data.Text (pack, Text)
  6. import Network.HTTP.Conduit (simpleHttp)
  7. import Network.HTTP.Types (status200)
  8. import Data.Digest.Pure.SHA (showDigest, sha1)
  9. import Database.Persist.Sqlite
  10. import Data.Maybe
  11. import Control.Exception.Lifted hiding (Handler)
  12. import Data.ByteString.Lazy.Internal (ByteString)
  13.  
  14. share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persist|
  15. Stuff
  16. value Text
  17. deriving Show
  18. |]
  19.  
  20. data Challenge = Challenge ConnectionPool
  21.  
  22. mkYesod "Challenge" [parseRoutes|
  23. /fib/#Int FibR
  24. /google-body GoogR GET
  25. /store StoreR POST GET
  26. |]
  27.  
  28. instance Yesod Challenge
  29.  
  30. instance RenderMessage Challenge FormMessage where
  31. renderMessage _ _ = defaultFormMessage
  32.  
  33. instance YesodPersist Challenge where
  34. type YesodPersistBackend Challenge = SqlPersist
  35.  
  36. runDB action = do
  37. Challenge pool <- getYesod
  38. runSqlPool action pool
  39.  
  40. handleFibR :: Int -> Handler RepJson
  41. handleFibR num = jsonToRepJson $ object ["response" .= show_fib]
  42. where
  43. show_fib = show $ fib num
  44. fib :: Int -> Int
  45. fib 0 = 0
  46. fib 1 = 1
  47. fib n = fib (n - 1) + fib (n - 2)
  48.  
  49. getGoogR :: Handler RepJson
  50. getGoogR = do
  51. body <- try (simpleHttp "http://www.google.com")
  52. case body of
  53. Left (SomeException ex) -> jsonToRepJson $ object ["response" .= ("ERROR: " ++ (show ex))]
  54. Right val -> jsonToRepJson $ object ["response" .= (showDigest $ sha1 val)]
  55.  
  56. postStoreR :: Handler ()
  57. postStoreR = do
  58. mvalue <- runInputPost $ ireq textField "value"
  59. runDB $ Y.insert $ Stuff mvalue
  60. sendResponseStatus status200 ()
  61.  
  62. getStoreR :: Handler RepJson
  63. getStoreR = do
  64. mvalue <- runDB $ Y.selectFirst [] [Y.Desc StuffValue, Y.LimitTo 1]
  65. case mvalue of
  66. Nothing -> jsonToRepJson $ object ["response" .= (show "NO DATA IN DATABASE")]
  67. Just mvalue' -> jsonToRepJson $ object ["response" .= (show . stuffValue $ Y.entityVal mvalue')]
  68.  
  69. main = withSqlitePool ":memory:" 10 $ \pool -> do
  70. runSqlPool (runMigration migrateAll) pool
  71. warpDebug 3000 $ Challenge pool

Project Euler: Problem 16

I'm not dead yet! I've just been insanely busy the last month or two with changing jobs and preparing my first programming presentation for BayPiggies and Silicon Valley Code Camp (which is a post for the near future). Both of these have kept me away from my blog. Let me make it up to you with a solution to project Euler problem #16.

The challenge is:

2^15 = 32768 and the sum of its digits is 3 + 2 + 7 + 6 + 8 = 26.
What is the sum of the digits of the number 21000?

Let's start with some Python code:

  1. #!/usr/bin/python
  2.  
  3. print sum([int(i) for i in str(2 ** 1000)])

For this solution, using a more functional approach definitely reduced the code base. But one thing I was a little surprised about is that having a list comprehension within the sum function is actually faster than a generator expression. Usually one hears how generator expressions are preferred over list comprehensions because they are more efficient with memory, among other reasons. However, it's actually faster to give sum a list. One quick caveat, this whole sum and list comprehension thing applies to Python 2. The same seems to be also be true for Python 3, at least from the interpreter:

  1. >>> import timeit
  2. >>> timeit.timeit("sum(int(x) for x in str(2 ** 1000))", number=1000)
  3. 0.11109958100132644
  4. >>> timeit.timeit("sum([int(x) for x in str(2 ** 1000)])", number=1000)
  5. 0.09597363900684286
  6. >>> timeit.timeit("sum(int(x) for x in str(2 ** 1000))", number=10000)
  7. 1.051396899012616
  8. >>> timeit.timeit("sum([int(x) for x in str(2 ** 1000)])", number=10000)
  9. 0.9054670640034601
  10. >>> timeit.timeit("sum(int(x) for x in str(2 ** 1000))", number=100000)
  11. 10.498383879996254
  12. >>> timeit.timeit("sum([int(x) for x in str(2 ** 1000)])", number=100000)
  13. 8.992312036993098

On to the Haskell code:

  1. module Main where
  2.  
  3. import Data.Char
  4.  
  5. main :: IO ()
  6. main = print . sum . map digitToInt . show $ 2 ^ 1000

Maybe it's just me and my Haskell/Python-centric brain, but I think the algorithm is simple enough to easily see the similarities and differences between the two languages. If I wanted to write the Haskell code to better match the Python code (syntactic differences aside), it would look like this: (inside the Haskell interpreter)

  1. Prelude Data.Char> print . sum $ [ digitToInt x | x <- show (2 ^ 1000)]

Even though this code may be easier to read for a Python programmer, it's not “good” Haskell code. It'll get the job done, but the map is obfuscated by the list comprehension. We can also adjust the Python code to make it resemble Haskell by using map:

print sum(map(int, str(2 ** 1000)))

But that might get you “dinged” because some people think that using map is “too functional” or “not Pythonic”, even if the code might be faster. I don't subscribe to that line of thinking...but that's a discussion for another time.

Times:
python – list comprehension : .032s
python – map : .030s
haskell – list ( interpreted) : .155s
haskell – map (interpreted) : .155s
haskell – list (compiled) : .006s
haskell – map (compiled) : .006s

As always, questions, comments, and complaints are encouraged. I hope everyone will forgive me for not posting for so long... sometimes life happens.

Project Euler: Problem 14

“The following iterative sequence is defined for the set of positive integers: n → n/2 (n is even) n → 3n + 1 (n is odd).  Using the rule above and starting with 13, we generate the following sequence: 13 → 40 → 20 → 10 → 5 → 16 → 8 → 4 → 2 → 1.  It can be seen that this sequence (starting at 13 and finishing at 1) contains 10 terms.  Although it has not been proved yet (Collatz Problem), it is thought that all starting numbers finish at 1.  Which starting number, under one million, produces the longest chain?  NOTE: Once the chain starts the terms are allowed to go above one million.”

Not many of you may be aware of this, but about a year ago I wrote up a blog post that discussed Collatz chains in Haskell.  You can find that post here: . Having some of the code already written made coming up with the solution easier.  However, just because I had one function doesn't mean I had the whole problem licked.  I still had a fair amount of work in front of me.  Below is my code from the first attempt at a solution:

  1. module Main where
  2.  
  3. import Data.List
  4.  
  5. chain' :: Integer -> [Integer]
  6. chain' 1 = [1]
  7. chain' n
  8.    | n <= 0 = []
  9.    | even n = n : chain' (n `div` 2)
  10.    | odd n = n : chain' (n * 3 + 1)
  11.  
  12. main :: IO ()
  13. main = do
  14.     let seqx = map chain' [3..1000000]
  15.     let lengthx = map length seqx
  16.     print . maximum $ zip lengthx seqx

This code appears to be logically correct but was incredibly slow - so slow that after over 2 minutes it still hadn’t completed.  I admit I can be a little impatient with these things from time to time, but in this case something was obviously wrong.

I devised two optimizations:

  • Reverse the order of the list. I will be more likely to find the number with the longest chain near 1,000,000 than 3.
  • Use odd numbers only. This is based on the fact that in the chain' function an odd number gets multiplied right off the bat, whereas an even number is instantly divided by 2, and also on the assumption that a higher number will be more likely to have a longer chain.  (I admit this was a complete experiment - I had no proof that it would work ahead of time, and knew it gave me the right answer only after the fact.)

The code then morphed into:

  1. module Main where
  2.  
  3. import Data.List
  4.  
  5. chain' :: Integer -> [Integer]
  6. chain' 1 = [1]
  7. chain' n
  8.    | n <= 0 = []
  9.    | even n = n : chain' (n `div` 2)
  10.    | odd n = n : chain' (n * 3 + 1)
  11.  
  12. main :: IO ()
  13. main = do
  14.     let seqx = map chain' [999999,999997..3]
  15.     let lengthx = map length seqx
  16.     print . maximum $ zip lengthx seqx

The problem I ran into with this code was that I received stack overflow errors; my list of tuples holding another long list of int’s was taking up to much memory.  I fixed this problem by computing the length of the list immediately after generating it.  The new code looked like this:

  1. import Data.List
  2.  
  3. chain' :: Integer -> [Integer]
  4. chain' 1 = [1]
  5. chain' n
  6.    | n <= 0 = []
  7.    | even n = n : chain' (n `div` 2)
  8.    | odd n = n : chain' (n * 3 + 1)
  9.  
  10. main :: IO ()
  11. main = do
  12.     let seqx = map (\x → (x, length $ chain' x) [999999,999997..3]
  13.     print . maximum $ seqx

This got me a result within the one minute time frame, but it still wasn't the right answer.  Can you figure out why?  Using the great code Jedai posted in the comments of my Apache log post, I was able to get my answer and finally complete the problem:

  1. module Main where                                                                             
  2.  
  3.  import Data.Tuple
  4.  import Data.List (sortBy)
  5.  import Data.Function (on)
  6.  
  7.  chain' :: Integer -> [Integer]
  8.  chain' 1 = [1]
  9.  chain' n
  10.    | n <= 0 = []
  11.    | even n = n : chain' (n `div` 2)
  12.    | odd n = n : chain' (n * 3 + 1)
  13.  
  14.  main :: IO ()
  15.  main = do
  16.      let seqx = map (\x -> (x, length $ chain' x)) [999999,999997..3]
  17.      print . fst . head $ sortBy (flip compare `on` snd) seqx

After figuring that out, getting the python answer was a breeze:

  1. #!/usr/bin/python
  2. """Python solution for Project Euler problem #14."""
  3.  
  4. from itertools import imap
  5.  
  6. def sequence(number):
  7. t_num = number
  8. count = 1
  9.  
  10. while(t_num > 1):
  11. if t_num % 2 == 0:
  12. t_num /= 2
  13. else:
  14. t_num = (t_num * 3) + 1
  15.  
  16. count += 1
  17.  
  18. return (count, number)
  19.  
  20. if __name__ == "__main__":
  21. print max(imap(sequence, xrange(999999,3,-2)))

Here are the speed numbers:
Haskell (complied) : 14.758s
Python : 18.537s
Haskell (runghc): 15.217s

I think the use of recursion in my Haskell code is affecting its speed of computation.  As I learned from problem 12, I can use the State Monad again to speed things up.  But I also learned from the comments of problem 12 that some people were able to substitute a scan or fold in the State Monad’s place.  So I decided to shoot for one more solution.  After studying up on scan and fold, and finding that neither was really what I wanted, I found iterate. Using iterate I was able to change the program to this:

  1. module Main where
  2.  
  3. import Data.Tuple
  4. import Data.List (sortBy, iterate)
  5. import Data.Function (on)
  6.  
  7. chain' :: Integer -> Int
  8. chain' n  
  9.     | n < 1 = 0
  10.     | otherwise = 1 + (length $ (takeWhile ( > 1) $ iterate (\x -> if even x then x `div` 2 else x * 3 + 1) n))
  11.  
  12. main :: IO ()
  13. main = do
  14.     let seqx = map (\x -> (x, chain' x)) [999999,999997..3]
  15.     print . fst . head $ sortBy (flip compare `on` snd) seqx

The new chain' function doesn't read as cleanly as the old one, but it does remove the recursion I was talking about earlier.  The computer gods rewarded my efforts by reducing the run times to these:

Haskell (complied) : 10.933s
Haskell (runghc): 11.744s

From 14.758 to 10.933 - almost 4 seconds taken off the clock!  I think a speed up like that calls for some celebrating.  Which is exactly what I'm going to do before I start on problem 15.

Project Euler: Problem 13

Problem thirteen from Project Euler is one of those problems that's so simple, I don't understand why it's in the double digits section. The problem reads: “Work out the first ten digits of the sum of the following one-hundred 50-digit numbers.”
It then proceeds to list 100 long numbers. I'm not going to paste them here because they are in the code solutions below and I don't want to clog up the “tubez” with more redundant information than I'm about to.

Enough of my jibber-jabber. Here is my Haskell solution first (trying to change things up here):

  1. module Main where
  2.  
  3. main :: IO()
  4. main = do
  5. print . take 10 . show $ sum big_number
  6. where big_number = [ 37107287533902102798797998220837590246510135740250
  7. , 46376937677490009712648124896970078050417018260538
  8. , 74324986199524741059474233309513058123726617309629
  9. , 91942213363574161572522430563301811072406154908250
  10. , 23067588207539346171171980310421047513778063246676
  11. , 89261670696623633820136378418383684178734361726757
  12. , 28112879812849979408065481931592621691275889832738
  13. , 44274228917432520321923589422876796487670272189318
  14. , 47451445736001306439091167216856844588711603153276
  15. , 70386486105843025439939619828917593665686757934951
  16. , 62176457141856560629502157223196586755079324193331
  17. , 64906352462741904929101432445813822663347944758178
  18. , 92575867718337217661963751590579239728245598838407
  19. , 58203565325359399008402633568948830189458628227828
  20. , 80181199384826282014278194139940567587151170094390
  21. , 35398664372827112653829987240784473053190104293586
  22. , 86515506006295864861532075273371959191420517255829
  23. , 71693888707715466499115593487603532921714970056938
  24. , 54370070576826684624621495650076471787294438377604
  25. , 53282654108756828443191190634694037855217779295145
  26. , 36123272525000296071075082563815656710885258350721
  27. , 45876576172410976447339110607218265236877223636045
  28. , 17423706905851860660448207621209813287860733969412
  29. , 81142660418086830619328460811191061556940512689692
  30. , 51934325451728388641918047049293215058642563049483
  31. , 62467221648435076201727918039944693004732956340691
  32. , 15732444386908125794514089057706229429197107928209
  33. , 55037687525678773091862540744969844508330393682126
  34. , 18336384825330154686196124348767681297534375946515
  35. , 80386287592878490201521685554828717201219257766954
  36. , 78182833757993103614740356856449095527097864797581
  37. , 16726320100436897842553539920931837441497806860984
  38. , 48403098129077791799088218795327364475675590848030
  39. , 87086987551392711854517078544161852424320693150332
  40. , 59959406895756536782107074926966537676326235447210
  41. , 69793950679652694742597709739166693763042633987085
  42. , 41052684708299085211399427365734116182760315001271
  43. , 65378607361501080857009149939512557028198746004375
  44. , 35829035317434717326932123578154982629742552737307
  45. , 94953759765105305946966067683156574377167401875275
  46. , 88902802571733229619176668713819931811048770190271
  47. , 25267680276078003013678680992525463401061632866526
  48. , 36270218540497705585629946580636237993140746255962
  49. , 24074486908231174977792365466257246923322810917141
  50. , 91430288197103288597806669760892938638285025333403
  51. , 34413065578016127815921815005561868836468420090470
  52. , 23053081172816430487623791969842487255036638784583
  53. , 11487696932154902810424020138335124462181441773470
  54. , 63783299490636259666498587618221225225512486764533
  55. , 67720186971698544312419572409913959008952310058822
  56. , 95548255300263520781532296796249481641953868218774
  57. , 76085327132285723110424803456124867697064507995236
  58. , 37774242535411291684276865538926205024910326572967
  59. , 23701913275725675285653248258265463092207058596522
  60. , 29798860272258331913126375147341994889534765745501
  61. , 18495701454879288984856827726077713721403798879715
  62. , 38298203783031473527721580348144513491373226651381
  63. , 34829543829199918180278916522431027392251122869539
  64. , 40957953066405232632538044100059654939159879593635
  65. , 29746152185502371307642255121183693803580388584903
  66. , 41698116222072977186158236678424689157993532961922
  67. , 62467957194401269043877107275048102390895523597457
  68. , 23189706772547915061505504953922979530901129967519
  69. , 86188088225875314529584099251203829009407770775672
  70. , 11306739708304724483816533873502340845647058077308
  71. , 82959174767140363198008187129011875491310547126581
  72. , 97623331044818386269515456334926366572897563400500
  73. , 42846280183517070527831839425882145521227251250327
  74. , 55121603546981200581762165212827652751691296897789
  75. , 32238195734329339946437501907836945765883352399886
  76. , 75506164965184775180738168837861091527357929701337
  77. , 62177842752192623401942399639168044983993173312731
  78. , 32924185707147349566916674687634660915035914677504
  79. , 99518671430235219628894890102423325116913619626622
  80. , 73267460800591547471830798392868535206946944540724
  81. , 76841822524674417161514036427982273348055556214818
  82. , 97142617910342598647204516893989422179826088076852
  83. , 87783646182799346313767754307809363333018982642090
  84. , 10848802521674670883215120185883543223812876952786
  85. , 71329612474782464538636993009049310363619763878039
  86. , 62184073572399794223406235393808339651327408011116
  87. , 66627891981488087797941876876144230030984490851411
  88. , 60661826293682836764744779239180335110989069790714
  89. , 85786944089552990653640447425576083659976645795096
  90. , 66024396409905389607120198219976047599490197230297
  91. , 64913982680032973156037120041377903785566085089252
  92. , 16730939319872750275468906903707539413042652315011
  93. , 94809377245048795150954100921645863754710598436791
  94. , 78639167021187492431995700641917969777599028300699
  95. , 15368713711936614952811305876380278410754449733078
  96. , 40789923115535562561142322423255033685442488917353
  97. , 44889911501440648020369068063960672322193204149535
  98. , 41503128880339536053299340368006977710650566631954
  99. , 81234880673210146739058568557934581403627822703280
  100. , 82616570773948327592232845941706525094512325230608
  101. , 22918802058777319719839450180888072429661980811197
  102. , 77158542502016545090413245809786882778948721859617
  103. , 72107838435069186155435662884062257473692284509516
  104. , 20849603980134001723930671666823555245252804609722
  105. , 53503534226472524250874054075591789781264330331690]

followed by my Python solution:

  1. #!/usr/bin/python
  2. """
  3. code solution for project euler's problem #13 in python.
  4. """
  5. from __future__ import print_function
  6.  
  7. def print_10(number):
  8. print(str(number)[0:10])
  9.  
  10. if __name__ == "__main__":
  11.  
  12. big_number = [ 37107287533902102798797998220837590246510135740250,
  13. 46376937677490009712648124896970078050417018260538,
  14. 74324986199524741059474233309513058123726617309629,
  15. 91942213363574161572522430563301811072406154908250,
  16. 23067588207539346171171980310421047513778063246676,
  17. 89261670696623633820136378418383684178734361726757,
  18. 28112879812849979408065481931592621691275889832738,
  19. 44274228917432520321923589422876796487670272189318,
  20. 47451445736001306439091167216856844588711603153276,
  21. 70386486105843025439939619828917593665686757934951,
  22. 62176457141856560629502157223196586755079324193331,
  23. 64906352462741904929101432445813822663347944758178,
  24. 92575867718337217661963751590579239728245598838407,
  25. 58203565325359399008402633568948830189458628227828,
  26. 80181199384826282014278194139940567587151170094390,
  27. 35398664372827112653829987240784473053190104293586,
  28. 86515506006295864861532075273371959191420517255829,
  29. 71693888707715466499115593487603532921714970056938,
  30. 54370070576826684624621495650076471787294438377604,
  31. 53282654108756828443191190634694037855217779295145,
  32. 36123272525000296071075082563815656710885258350721,
  33. 45876576172410976447339110607218265236877223636045,
  34. 17423706905851860660448207621209813287860733969412,
  35. 81142660418086830619328460811191061556940512689692,
  36. 51934325451728388641918047049293215058642563049483,
  37. 62467221648435076201727918039944693004732956340691,
  38. 15732444386908125794514089057706229429197107928209,
  39. 55037687525678773091862540744969844508330393682126,
  40. 18336384825330154686196124348767681297534375946515,
  41. 80386287592878490201521685554828717201219257766954,
  42. 78182833757993103614740356856449095527097864797581,
  43. 16726320100436897842553539920931837441497806860984,
  44. 48403098129077791799088218795327364475675590848030,
  45. 87086987551392711854517078544161852424320693150332,
  46. 59959406895756536782107074926966537676326235447210,
  47. 69793950679652694742597709739166693763042633987085,
  48. 41052684708299085211399427365734116182760315001271,
  49. 65378607361501080857009149939512557028198746004375,
  50. 35829035317434717326932123578154982629742552737307,
  51. 94953759765105305946966067683156574377167401875275,
  52. 88902802571733229619176668713819931811048770190271,
  53. 25267680276078003013678680992525463401061632866526,
  54. 36270218540497705585629946580636237993140746255962,
  55. 24074486908231174977792365466257246923322810917141,
  56. 91430288197103288597806669760892938638285025333403,
  57. 34413065578016127815921815005561868836468420090470,
  58. 23053081172816430487623791969842487255036638784583,
  59. 11487696932154902810424020138335124462181441773470,
  60. 63783299490636259666498587618221225225512486764533,
  61. 67720186971698544312419572409913959008952310058822,
  62. 95548255300263520781532296796249481641953868218774,
  63. 76085327132285723110424803456124867697064507995236,
  64. 37774242535411291684276865538926205024910326572967,
  65. 23701913275725675285653248258265463092207058596522,
  66. 29798860272258331913126375147341994889534765745501,
  67. 18495701454879288984856827726077713721403798879715,
  68. 38298203783031473527721580348144513491373226651381,
  69. 34829543829199918180278916522431027392251122869539,
  70. 40957953066405232632538044100059654939159879593635,
  71. 29746152185502371307642255121183693803580388584903,
  72. 41698116222072977186158236678424689157993532961922,
  73. 62467957194401269043877107275048102390895523597457,
  74. 23189706772547915061505504953922979530901129967519,
  75. 86188088225875314529584099251203829009407770775672,
  76. 11306739708304724483816533873502340845647058077308,
  77. 82959174767140363198008187129011875491310547126581,
  78. 97623331044818386269515456334926366572897563400500,
  79. 42846280183517070527831839425882145521227251250327,
  80. 55121603546981200581762165212827652751691296897789,
  81. 32238195734329339946437501907836945765883352399886,
  82. 75506164965184775180738168837861091527357929701337,
  83. 62177842752192623401942399639168044983993173312731,
  84. 32924185707147349566916674687634660915035914677504,
  85. 99518671430235219628894890102423325116913619626622,
  86. 73267460800591547471830798392868535206946944540724,
  87. 76841822524674417161514036427982273348055556214818,
  88. 97142617910342598647204516893989422179826088076852,
  89. 87783646182799346313767754307809363333018982642090,
  90. 10848802521674670883215120185883543223812876952786,
  91. 71329612474782464538636993009049310363619763878039,
  92. 62184073572399794223406235393808339651327408011116,
  93. 66627891981488087797941876876144230030984490851411,
  94. 60661826293682836764744779239180335110989069790714,
  95. 85786944089552990653640447425576083659976645795096,
  96. 66024396409905389607120198219976047599490197230297,
  97. 64913982680032973156037120041377903785566085089252,
  98. 16730939319872750275468906903707539413042652315011,
  99. 94809377245048795150954100921645863754710598436791,
  100. 78639167021187492431995700641917969777599028300699,
  101. 15368713711936614952811305876380278410754449733078,
  102. 40789923115535562561142322423255033685442488917353,
  103. 44889911501440648020369068063960672322193204149535,
  104. 41503128880339536053299340368006977710650566631954,
  105. 81234880673210146739058568557934581403627822703280,
  106. 82616570773948327592232845941706525094512325230608,
  107. 22918802058777319719839450180888072429661980811197,
  108. 77158542502016545090413245809786882778948721859617,
  109. 72107838435069186155435662884062257473692284509516,
  110. 20849603980134001723930671666823555245252804609722,
  111. 53503534226472524250874054075591789781264330331690]
  112.  
  113. print_10(sum(big_number))

and to continue adding in the spice, I have included a solution in Scala:

  1. import BigInt._
  2.  
  3. object problem_13 {
  4. def main (args : Array[String]){
  5. val big_number = List("37107287533902102798797998220837590246510135740250",
  6. "46376937677490009712648124896970078050417018260538",
  7. "74324986199524741059474233309513058123726617309629",
  8. "91942213363574161572522430563301811072406154908250",
  9. "23067588207539346171171980310421047513778063246676",
  10. "89261670696623633820136378418383684178734361726757",
  11. "28112879812849979408065481931592621691275889832738",
  12. "44274228917432520321923589422876796487670272189318",
  13. "47451445736001306439091167216856844588711603153276",
  14. "70386486105843025439939619828917593665686757934951",
  15. "62176457141856560629502157223196586755079324193331",
  16. "64906352462741904929101432445813822663347944758178",
  17. "92575867718337217661963751590579239728245598838407",
  18. "58203565325359399008402633568948830189458628227828",
  19. "80181199384826282014278194139940567587151170094390",
  20. "35398664372827112653829987240784473053190104293586",
  21. "86515506006295864861532075273371959191420517255829",
  22. "71693888707715466499115593487603532921714970056938",
  23. "54370070576826684624621495650076471787294438377604",
  24. "53282654108756828443191190634694037855217779295145",
  25. "36123272525000296071075082563815656710885258350721",
  26. "45876576172410976447339110607218265236877223636045",
  27. "17423706905851860660448207621209813287860733969412",
  28. "81142660418086830619328460811191061556940512689692",
  29. "51934325451728388641918047049293215058642563049483",
  30. "62467221648435076201727918039944693004732956340691",
  31. "15732444386908125794514089057706229429197107928209",
  32. "55037687525678773091862540744969844508330393682126",
  33. "18336384825330154686196124348767681297534375946515",
  34. "80386287592878490201521685554828717201219257766954",
  35. "78182833757993103614740356856449095527097864797581",
  36. "16726320100436897842553539920931837441497806860984",
  37. "48403098129077791799088218795327364475675590848030",
  38. "87086987551392711854517078544161852424320693150332",
  39. "59959406895756536782107074926966537676326235447210",
  40. "69793950679652694742597709739166693763042633987085",
  41. "41052684708299085211399427365734116182760315001271",
  42. "65378607361501080857009149939512557028198746004375",
  43. "35829035317434717326932123578154982629742552737307",
  44. "94953759765105305946966067683156574377167401875275",
  45. "88902802571733229619176668713819931811048770190271",
  46. "25267680276078003013678680992525463401061632866526",
  47. "36270218540497705585629946580636237993140746255962",
  48. "24074486908231174977792365466257246923322810917141",
  49. "91430288197103288597806669760892938638285025333403",
  50. "34413065578016127815921815005561868836468420090470",
  51. "23053081172816430487623791969842487255036638784583",
  52. "11487696932154902810424020138335124462181441773470",
  53. "63783299490636259666498587618221225225512486764533",
  54. "67720186971698544312419572409913959008952310058822",
  55. "95548255300263520781532296796249481641953868218774",
  56. "76085327132285723110424803456124867697064507995236",
  57. "37774242535411291684276865538926205024910326572967",
  58. "23701913275725675285653248258265463092207058596522",
  59. "29798860272258331913126375147341994889534765745501",
  60. "18495701454879288984856827726077713721403798879715",
  61. "38298203783031473527721580348144513491373226651381",
  62. "34829543829199918180278916522431027392251122869539",
  63. "40957953066405232632538044100059654939159879593635",
  64. "29746152185502371307642255121183693803580388584903",
  65. "41698116222072977186158236678424689157993532961922",
  66. "62467957194401269043877107275048102390895523597457",
  67. "23189706772547915061505504953922979530901129967519",
  68. "86188088225875314529584099251203829009407770775672",
  69. "11306739708304724483816533873502340845647058077308",
  70. "82959174767140363198008187129011875491310547126581",
  71. "97623331044818386269515456334926366572897563400500",
  72. "42846280183517070527831839425882145521227251250327",
  73. "55121603546981200581762165212827652751691296897789",
  74. "32238195734329339946437501907836945765883352399886",
  75. "75506164965184775180738168837861091527357929701337",
  76. "62177842752192623401942399639168044983993173312731",
  77. "32924185707147349566916674687634660915035914677504",
  78. "99518671430235219628894890102423325116913619626622",
  79. "73267460800591547471830798392868535206946944540724",
  80. "76841822524674417161514036427982273348055556214818",
  81. "97142617910342598647204516893989422179826088076852",
  82. "87783646182799346313767754307809363333018982642090",
  83. "10848802521674670883215120185883543223812876952786",
  84. "71329612474782464538636993009049310363619763878039",
  85. "62184073572399794223406235393808339651327408011116",
  86. "66627891981488087797941876876144230030984490851411",
  87. "60661826293682836764744779239180335110989069790714",
  88. "85786944089552990653640447425576083659976645795096",
  89. "66024396409905389607120198219976047599490197230297",
  90. "64913982680032973156037120041377903785566085089252",
  91. "16730939319872750275468906903707539413042652315011",
  92. "94809377245048795150954100921645863754710598436791",
  93. "78639167021187492431995700641917969777599028300699",
  94. "15368713711936614952811305876380278410754449733078",
  95. "40789923115535562561142322423255033685442488917353",
  96. "44889911501440648020369068063960672322193204149535",
  97. "41503128880339536053299340368006977710650566631954",
  98. "81234880673210146739058568557934581403627822703280",
  99. "82616570773948327592232845941706525094512325230608",
  100. "22918802058777319719839450180888072429661980811197",
  101. "77158542502016545090413245809786882778948721859617",
  102. "72107838435069186155435662884062257473692284509516",
  103. "20849603980134001723930671666823555245252804609722",
  104. "53503534226472524250874054075591789781264330331690") map {BigInt(_)}
  105. val sums = big_number sum
  106. val su = sums toString
  107. val su10 = su take 10
  108. println(su10)
  109. }
  110. }

Some of you may be wondering, “Why a Scala solution?” To which I respond, “Why not?” Because that's a little short, I'll add that it has something to do with Scala starting to gain traction in the industry and me seeing if I would like to get paid to program in it.

The solution, in all three languages, is pretty simple. The recipe essentially says, “Put all numbers into a list. Get the sum of that list, turn that number into a string, and get the first 10 characters of that string.”

Times:
Haskell (compiled) : real 0m0.004s
Haskell (runghc) : real 0m0.314s
Python : real 0m0.059s
Scala (compiled) : real 0m0.757s

For the most part it's pretty standard in these tests to see performance times such that Haskell (compiled) < Python < Haskell (runghc). Java and Perl usually fall somewhere between the Haskell (compiled) and Python, in that order. To see Scala be 2x slower than Haskell (runghc) was a shocker. The only thing that makes sense to me for the slowdown is having to use the BigInt library. That is probably the biggest thing I took away from these time tests - if I want to do REALLY large number crunching and performance DOES matter, JVM-based languages might not be the best option.

A few thoughts on Scala:
If I haven't stated it already in this blog, I should now give the disclaimer that I'm not a Java fan. I know it still has its loyal followers, but I'm not one of them. Moving on. This was my first time working with Scala, and I'd like to finally welcome Java to the 21st century. While doing some research on the Scala language itself I read that “the industry” was moving to replace Java with Scala. I welcome that change. Does that mean I “like” Scala? The honest answer is, to butcher the quote the appliances from the Flintstones, “Eh, it's a language.” Scala is definitely an improvement over Java – not really that hard to do in my opinion – but, the language still feels unpolished. One quick way to kill the interpreter in Scala is to type “Int” then hit the enter key. Instead of error-ing out, the interpreter does a great job of interpreting a crash test car hitting a cement wall (I had to restart the whole thing.) When I tried the same “technique” in the Python interpreter, I got as a response and for Haskell's interpreter I received “Not in scope: data constructor `Int'”. I also found Scala's function composition to be a little lacking when compared to Haskell. I wasn't able to cleanly change the BigInt data type to String, and then only print out ten characters without requiring three separate val's. Yes, I could have used one var instead, but that's beside the point. I will admit it could be my inexperience with the language showing, so if anyone knows a smoother way to do this in Scala please share it in the comments.

All that being said, I do like the way Scala is trying to handle the reducing of Java's dot notation, and I think it's starting to make strides in the right direction in other areas. I'm open to working with Scala more, and look forward to seeing how it evolves over the next few years.

If you made it this far down into the article, hopefully you liked it enough to share it with your friends. Thanks if you do, I appreciate it.

Bookmark and Share

Syndicate content