Project Euler 58 - is there an anti-pattern in my solution?

Question

I'm currently working on the 58^th problem from Project Euler.

While my solution runs fine when I set the limit to 8%, it goes beyond one minute after that.

This surprises me, because I use a library for the primes generation and what I do by myself looks linear to me, and fine.

Though obviously I've missed plenty of huge thunks, quadratic (or worse) functions, bottlenecks etc before, and it must be the same here again.

What I'd like is a chek of my solution to know if the code is wrong, or if it's the way I handle the problem that's stupid. In the latter case, I'd like not to be spoiled.

I consider my question not to be a code review one, because basically my code doesn't work for its purpose, but I might be wrong, in which case please transfer the question to the appropriate SE site.

I tried literate programming for this one, so I'll just dump my file to provide further explanations.

My .lhs (well, formatted for SO)

We don't handle the primes ourselves and we want help from the compiler.

{-# OPTIONS_GHC -Wall #-}

import Data.Numbers.Primes

First, we construct in diags the stream of the numbers that are on the diagonals. To do that, we notice that those numbers get incremented 4 times in a row by a certain number, and then again with this number + 2, etc.
replicate 4 [2, 4..] will give us a list of increments.

Then we just need to aggregate all that with a scanl (+) and there we have our list.

primesDiags :: [Int]
primesDiags = go diags primes
  where
    diags = scanl (+) 1 . concatMap (replicate 4) $ [2, 4..] :: [Integer]

Once we have this list, we map all the numbers to 0 if the number is composite and 1 if the number is prime. To do that efficiently, we use a library to provide the stream of primes and map the two lists by running through them once only.

    go dss@(d:ds) pss@(p:ps) | d < p = 0:go ds pss
                             | d > p = go dss ps
                             | otherwise = 1:go ds ps

Then we tell ghc we know why our pattern matching is incomplete

    go _ _ = undefined -- we operate on streams

Now we have everything we need to answer the problem. Next step is to find at which square we cross the specific limit we seek to spot. To do that we simply update an accumulator to represent the number of primes we met up until this point and we keep track of the index of the square we're at too.

We start the recursion at 2 to just keep track of factorized behaviour. That's why we skip one item in primesDiags and since this item is 1 we set our acc to 0 (1 isn't prime).

nthSquare :: Int
nthSquare = go 2 (tail primesDiags) 0
  where
    go n (w:x:y:_:ds) primeN | 8 * primeN' < compositeN' = n
                             | otherwise = go (n + 1) ds primeN'
      where
        total = 4 * n - 3
        delta = sum [w, x, y]
        primeN' = primeN + delta
        compositeN' = total - primeN'
    go _ _ _ = undefined -- we operate on streams

Then, once we've spot the correct square, its side length is obtained by doubling its index and substracting one.

main :: IO ()
main = print $ nthSquare * 2 - 1

Here is a paste if you want to play with the code.

Answer 1

Not that the rest cannot be improved at all, but the library you used for prime generation isn't too fast. Using your code, I got

$./euler58 +RTS -s -RTS
11297
  30,958,460,200 bytes allocated in the heap
   4,671,021,104 bytes copied during GC
         495,832 bytes maximum residency (2822 sample(s))
          47,664 bytes maximum slop
               3 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0     56551 colls,     0 par    5.96s    5.97s     0.0001s    0.0004s
  Gen  1      2822 colls,     0 par    1.60s    1.61s     0.0006s    0.0014s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   21.47s  ( 21.50s elapsed)
  GC      time    7.56s  (  7.57s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   29.04s  ( 29.08s elapsed)

  %GC     time      26.1%  (26.0% elapsed)

  Alloc rate    1,441,874,868 bytes per MUT second

  Productivity  73.9% of total user, 73.8% of total elapsed

Changing the import to

import Math.NumberTheory.Primes

(from the arithmoi package - disclaimer, I'm the author) and the first line of primesDiags to

primesDiags = go diags (map fromInteger primes)

the result is

$ ./aeuler58 +RTS -s -RTS
11297
   1,986,441,440 bytes allocated in the heap
      25,254,256 bytes copied during GC
         220,328 bytes maximum residency (34 sample(s))
         158,984 bytes maximum slop
               2 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      3761 colls,     0 par    0.06s    0.06s     0.0000s    0.0002s
  Gen  1        34 colls,     0 par    0.00s    0.00s     0.0001s    0.0001s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time    0.96s  (  0.96s elapsed)
  GC      time    0.06s  (  0.06s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time    1.02s  (  1.02s elapsed)

  %GC     time       5.9%  (5.9% elapsed)

  Alloc rate    2,064,058,991 bytes per MUT second

  Productivity  94.1% of total user, 94.1% of total elapsed

which shows that your part of the code is decent. You can improve it by using the fact that on one of the spikes there are the squares, so that that needn't be considered at all.

Another point is that instead of computing all primes, you could just inspect the values on the diagonals (ignoring the squares) and check which of them are prime if you have a fast prime check. Whether that's faster depends on the prime check.