I find it really difficult to understand the mechanics of the following recursive function:
sums (x:y:ys) = x:sums(x + y : ys)
sums xs = xs
sums ([0..4])
Output:
[0, 1, 3, 6, 10]
What exactly happens in this line?:
x:sums(x + y : ys)
I would say that before the program can append the 'x' to the list, the function sum(x + y : ys) has to be executed first. But in that case, 'x' would be appended to the list only once - at the end of the recursion loop - which wouldn't result in the given output... so where are the flaws in my logic?
My follow-up question: how should I look at/treat recursive functions in a logical way, that will (hopefully) lead me to an 'aha-erlebnis'?
Any help is much appreciated!
You can understand Haskell code by stepwise reduction. Maybe the following example reduction sequence helps with your aha.
(A Haskell implementation actually does something related to such reduction steps, but maybe in a different order. You get the same end result, though).
In this example, you start with:
sums [0..4]
Expand the [0..4] notation a bit:
sums (0 : 1 : [2..4])
Now we see that the first equation of sums matches, with x = 0, y = 1, and ys = [2..4]. So we get:
0 : sums (0 + 1 : [2..4])
We can compute 0 + 1:
0 : sums (1 : [2..4])
And expand [2..4] a bit:
0 : sums (1 : 2 : [3..4])
Now we see that the first equation of sums matches again, this time with x = 1, y = 2, and ys = [3..4]. So we get:
0 : 1 : sums (1 + 2 : [3..4])
We can compute 1 + 2:
0 : 1 : sums (3 : [3..4])
And expand [3..4] a bit:
0 : 1 : sums (3 : 3 : [4..4])
Now we see that the first equation of sums matches again, this time with x = 3, y = 3, and ys = [4..4]. So we get:
0 : 1 : 3 : sums (3 + 3 : [4..4])
We can compute 3 + 3:
0 : 1 : 3 : sums (6 : [4..4])
And expand [4..4]:
0 : 1 : 3 : sums (6 : 4 : [])
Now we see that the first equation of sums matches again, this time with x = 6, y = 4, and ys = []. So we get:
0 : 1 : 3 : 6 : sums (6 + 4 : [])
We can compute 6 + 4:
0 : 1 : 3 : 6 : sums (10 : [])
This time, the first equation for sums doesn't match. But the second equation matches. So we get:
0 : 1 : 3 : 6 : 10 : []
This is the observed output [0, 1, 3, 6, 10].
This is no different than recursion in any other langauge. When sums [0..4] (the parentheses are unnecessary) is first called, x==0, y==1, and ys == [2..4]. Thus, the return value is a new list created from 0 and sums [1..4].
In a strict language, the recursive call would complete before finally creating the new list. Since Haskell is lazy, a list starting with 0 and continuing with a promise to evaluate sums [1..4] is returned. The recursive call won't actually be evaluated until someone actually tries to access the tail of the list.
You could notice that
sums (x:y:ys) = x:sums(x + y : ys)
is equivalent to
sums (x:y:z:ys) = x:x+y:sums(x+y+z : ys)
sums (x:y:ys) = x:sums(x + y : ys)
and (with more than 2 items) is also equivalent to
sums (x:y:z: w: ys) = x:x+y:x+y+z:sums(x+y+z +w: ys)
sums (x:y:z:ys) = x:x+y:sums(x+y+z : ys)
sums (x:y:ys) = x:sums(x + y : ys)
so by induction you have that
sums(1:2:3:4 :[])
is equal to
1 : 1 + 2 : 1 + 2 + 3 : 1 + 2 + 3 + 4 : []
Based on the above you can also predict that with
fact(x:y:ys) = x: fact(x * y : ys)
fact(xs) = xs
then
fact([1..4])
is
1:1*2:1*2*3:1*2*3*4:[]
There are two equation that define the function sums. Keep rewriting an expression that involves sums using the first equation that matches the argument, or other suitable equations (like 1+2=3).
sums [0..4] =
-- by syntactic sugar
sums (0:1:2:3:4:[]) =
-- by eq. 1, x=0,y=1,ys=2:3:4:[]
0 : sums ((0+1) : 2 : 3:4:[]) =
-- by addition
0 : sums (1 : 2 : 3:4:[]) =
-- by eq. 1, x=1, y=2, ys=3:4:[]
0 : 1 : sums ((1+2) : 3 : 4:[]) =
-- by addition
0 : 1 : sums (3 : 3 : 4:[]) =
-- by eq. 1, x=3, y=3, ys=4:[]
0 : 1 : 3 : sums ((3+3) : 4 : []) =
-- by addition
0 : 1 : 3 : sums (6 : 4 : []) =
-- by eq. 1, x=6, y=4, ys=[]
0 : 1 : 3 : 6 : sums ((6+4):[]) =
-- by addition
0 : 1 : 3 : 6 : sums (10:[]) =
-- by eq 2,xs=(10:[])
0 : 1 : 3 : 6 : 10 : [] =
-- by syntactic sugar
[0,1,3,6,10]
Related
I would like to ask how to choose increasing subsequence of elements from a list in Haskell. The rule is that in a not empty list the first element is chosen and then every element that is bigger than the previously chosen element. For example in a list [3,1,8,4,6,7,9,2,11,4,3]
would be chosen sublist [3,8,9,11].
My code so far doesn't cover the problem completely:
incrSub :: Ord a => [a] -> [a]
incrSub [] = []
incrSub (x:xs) = if x < head xs then x: incrSub (xs) else incrSub (xs)
Consider the evaluation of your function on the provided sample input:
incrSub [3, 1, 8, 4, 6, 7, 9, 2, 11, 4, 3]
incrSub (3 : 1 : 8 : 4 : 6 : 7 : 9 : 2 : 11 : 4 : 3 : [])
3 < 1 == False → incrSub (1 : 8 : 4 : 6 : 7 : 9 : 2 : 11 : 4 : 3 : [])
1 < 8 == True → 1 : incrSub (8 : 4 : 6 : 7 : 9 : 2 : 11 : 4 : 3 : [])
8 < 4 == False → 1 : incrSub (4 : 6 : 7 : 9 : 2 : 11 : 4 : 3 : [])
4 < 6 == True → 1 : 4 : incrSub (6 : 7 : 9 : 2 : 11 : 4 : 3 : [])
6 < 7 == True → 1 : 4 : 6 : incrSub (7 : 9 : 2 : 11 : 4 : 3 : [])
7 < 9 == True → 1 : 4 : 6 : 7 : incrSub (9 : 2 : 11 : 4 : 3 : [])
9 < 2 == False → 1 : 4 : 6 : 7 : incrSub (2 : 11 : 4 : 3 : [])
2 < 11 == True → 1 : 4 : 6 : 7 : 2 : incrSub (11 : 4 : 3 : [])
11 < 4 == False → 1 : 4 : 6 : 7 : 2 : incrSub (4 : 3 : [])
4 < 3 == False → 1 : 4 : 6 : 7 : 2 : incrSub (3 : [])
3 < undefined == undefined → 1 : 4 : 6 : 7 : 2 : undefined
Notice the relationship between the actual result and the expected result:
input 3 : 1 : 8 : 4 : 6 : 7 : 9 : 2 : 11 : 4 : 3 : []
expected 3 : 8 : 9 : 11 : []
actual 1 : 4 : 6 : 7 : 2 : undefined
So this suggests a few things to look at:
Your condition is filtering the opposite of what you intended.
You are not handling the end of the list correctly. In particular, consider the case of a 1-element list incrSub [42].
Your code is prone to errors because you’re using head, which is a partial function. Preferring pattern-matching may help, especially if you enable warnings (e.g. passing -Wall to GHC or adding {-# GHC_OPTIONS -Wall #-} to your file). Recall that you can use nested patterns like x1 : x2 : xs to match a list of at least 2 elements x1 and x2.
Working through examples like this using equational reasoning is a very powerful debugging technique for Haskell code. You can also use property-based testing libraries like QuickCheck to identify test cases that fail. For example, it quickly identifies the minimal failing test case of singleton lists:
> import Test.QuickCheck (quickCheck)
> resultIsSorted :: [Int] -> Bool; resultIsSorted input = let { result = incrSub input } in result == sort result
> quickCheck resultIsSorted
*** Failed! Exception: 'Prelude.head: empty list' (after 2 tests and 2 shrinks):
[0]
You can write more complex properties to find more interesting edge cases.
the function nth must work like this :
# nth [1;2;3;4;5] 0;;
- : int = 1
# nth [1;2;3;4;5] 1;;
- : int = 2
# nth [1;2;3;4;5] 2;;
- : int = 3
# nth [1;2;3;4;5] 3;;
- : int = 4
I wrote this function named nth like this :
let rec nth l n =
match l with
|[] -> raise (Failure "list is too short")
|hd::tl ->
if n > 0 then nth tl n-1 else hd
So I typed nth [1;2;3;4;5] 3 and the expected output was 4 but the console said "list is too short"
My expected algorithm is this :
nth [1;2;3;4;5] 3
1::[2;3;4;5] 3 > 0 is true, so nth [2;3;4;5] 2 is called.
2::[3;4;5] 2 > 0 is true, so nth [3;4;5] 1 is called.
3::[4,5] 1 > 0 is true, so nth [4;5] 0 is called
4::[5] 0 > 0 is false, so return 4
so nth [1;2;3;4;5] 3 = 4
What is wrong with my code?
This is a precedence problem. The expression nth tl n-1 is parsed like this: (nth tl n) - 1. You need parentheses like this: nth tl (n - 1).
If you try your current code with a list of strings (say), you'll get a possibly more helpful error message from the toplevel.
Other than this one problem your code looks excellent btw.
I have this haskell function that I don't quite understand.
ns :: [Integer]
ns = 0 : [n+k | (n, k) <- zip ns [1,3..]]
I am asked to "take 3 ns".
I thought ns was constant so it would only zip with the first element of the list, giving (0,1). Then when added gives an answer of 1. Then it says "take 3 ns" so I zipped 0 with the first 5 elements of the list, giving... (0,1),(0,3), (0,5) and then when added, I get a final answer of [1,3,5]. However this isn't the correct answer.
What is actually happening to ns? I'm struggling to understand...
haskell is lazy so you can have recursive definitions. Here it is laid out.
ns = 0 : something
(n,k) <- zip (0 : something ) [1,3,5,7...]
(n,k) <- [(0,1) : something )
ns = 0 : 1 : something
(n,k) <- zip ( 0 : 1 : something ) [3,5,7...]
(n,k) <- (0,1) : (1,3) : something
ns = 0 : 1 : 4 : something
(n,k) <- zip ( 0 : 1 : 4 : something ) [5,7...]
(n,k) <- (0,1) : (1,3) : (4,5) : something
ns = 0 : 1 : 4 : 9 : something
....
See how we determine what the next tuple is then add its two elements. This allows us to determine the next element.
Everything in Haskell is lazy, so while ns is constant, that doesn't mean items in the list can't be "added" (or more accurately, "computed") at a later time. Also, because ns is recursively defined, values that appear later in the list can depend on values that appear earlier in the list.
Let's go over this step by step.
First, we know that ns starts with 0, so for the time being, ns looks like this:
ns: 0, ?, ?, ...
So what's in the first question mark? According to your function, it's n + k, where n is the first element in ns, and k is the first element in [1, 3..]. So n = 0, k = 1, and n + k = 1.
ns: 0, 1, ?, ...
Moving on, the next element is also n + k, where we use the second elements of ns and [1, 3...]. We now know that the second element of ns is 1, so n = 1, k = 3, and n + k = 4.
ns: 0, 1, 4, ...
And so on.
Haskell evaluates things lazily, so it'll only compute exactly as much of a value is needed. That means we need to somehow need values of ns to see how it's computed.
head ns
head (0 : ...)
0
Clearly, head doesn't force enough for anything interesting to happen, but you can already see that the interesting part of ns is just discarded. That effect goes further when we ask for more, such as printing each element. Let's just force each element one after another to see the pattern. First, let's replace the list comprehension with a single equivalent function call
zipWith f [] _ = []
zipWith f _ [] = []
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
ns = 0 : zipwith (+) ns [1,3..]
Now we can evaluate elements of ns one by one. Really, to be more detailed, we're evaluating ns and determining that the first constructor is (:) and then deciding to evaluate the second argument to (:) as our next step. I'll use {...} to represent a not-yet-evaluated thunk.
ns
{ 0 } : zipWith (+) ns [1,3...]
{ 0 } : zipWith (+) ({ 0 } : { ... }) [1,3...] -- notice the { 0 } thunk gets evaluated
0 : { 0 + 1 } : zipWith f { ... } [3,5...]
0 : 1 : { 1 + 3 } : zipWith f { ... } [5,7...]
0 : 1 : 4 : { 4 + 5 } : zipWith f { ... } [7,9...]
What's important to note above is that since ns get evaluated only piece by piece, it never demands to know something that has not yet been computed. In this way, ns forms a tight, clever little loop all in itself.
That's equivalent to ns = 0 : (zipWith (+) ns [1,3,...]) , which may be easier to comprehend: the k+1th element is the kth element plus k-th odd number, with appropriate starting conditions.
ns :: [Integer]
ns = 0 : [n+k | (n, k) <- zip ns [1,3..]]
this is a corecursive data definition. ns is a constant, a list, but it is "fleshed out" by access, since Haskell is lazy.
An illustration:
1 n1 n2 n3 n4 n5 ... -- the list ns, [n1,n2,n3,...],
2 0 1 4 ... -- starts with 0
3 -----------------
4 1 3 5 7 9 -- [1,3..]
5 -----------------
6 1 4 ... -- sum the lines 2 and 4 pairwise, from left to right, and
7 n2 n3 n4 n5 ... -- store the results starting at (tail ns), i.e. from n2
We can see precisely how access is forcing the list ns into existence step by step, e.g. after print $ take 4 ns, by naming the interim entities:
ns :: [Integer]
ns = 0 : [n+k | (n, k) <- zip ns [1,3..]]
ns = 0 : tail1
tail1 = [n+k | (n, k) <- zip ns [1,3..]]
= [n+k | (n, k) <- zip (0 : tail1) [1,3..]]
= [n+k | (n, k) <- (0,1) : zip tail1 [3,5..]]
= 1 : [n+k | (n, k) <- zip tail1 [3,5..]]
= 1 : tail2
tail2 = [n+k | (n, k) <- zip (1 : tail2) [3,5..]]
= [n+k | (n, k) <- (1,3) : zip tail2 [5,7..]]
= 4 : tail3
tail3 = [n+k | (n, k) <- zip (4 : tail3) [5,7..]]
= 9 : tail4
tail4 = [n+k | (n, k) <- zip (9 : tail4) [7,9..]]
------
ns = 0 : 1 : 4 : 9 : tail4
I have been messing with some Haskell functions, some I have understand and some don't.
For example if we do: scanl (+) 0 [1..3] my understanding is the following:
1. the accumulator is 0 acc = 0 |
2. (+) applied to acc and first el acc = 0 + 1 = 1 |
3. (+) applied to latest acc and snd el acc = 1 + 2 = 3 |
4. (+) applied to latest acc and third acc = 3 + 3 = 6 V
Now when we make the list we get [0, 1, 3, 6].
But I can't seem to understand how does scanr (+) 0 [1..3] gives me: [6,5,3,0]
Maybe scanr works the following way?
1. the first element in the list is the sum of all other + acc
2. the second element is the sum from right to left (<-) of the last 2 elements
3. the third element is the sum of first 2...
I don't see if that's the pattern or not.
scanr is to foldr what scanl is to foldl. foldr works from the right:
foldr (+) 0 [1,2,3] =
(1 + (2 + (3 + 0))) =
(1 + (2 + 3)) =
(1 + 5) =
6
-- [ 6, 5, 3, 0 ]
and scanr just shows the interim results in sequence: [6,5,3,0]. It could be defined as
scanr (+) z xs = foldr g [z] xs
where
g x ys#(y:_) = x+y : ys
scanl though should work like
scanl (+) 0 [1,2,3] =
0 : scanl (+) (0+1) [2,3] =
0 : 1 : scanl (+) (1+2) [3] =
0 : 1 : 3 : scanl (+) (3+3) [] =
0 : 1 : 3 : [6]
so it must be that
scanl (+) z xs = foldr f h xs z
where h z = [z]
f x ys z = z : ys (z + x)
scanl and scanr are used to show the value of the accumulator on each iteration. scanl iterates from left-to-right, and scanr from right-to-left.
Consider the following example:
scanl (+) 0 [1, 2, 3]
-- 0. `scanl` stores 0 as the accumulator and in the output list [0]
-- 1. `scanl` adds 0 and 1 and stores 1 as the accumulator and in the output list [0, 1]
-- 2. `scanl` adds 1 and 2 and stores 3 as the accumulator and in the output list [0, 1, 3]
-- 3. `scanl` adds 3 and 3 and stores 6 as the accumulator and in the output list [0, 1, 3, 6]
-- 4. `scanl` returns the output list [0, 1, 3, 6]
As you can see, scanl stores the results of the accumulator while it's iterating through the list. This is the same for scanr, but the list is iterated in reverse.
Here's another example:
scanl (flip (:)) [] [1, 2, 3]
-- [[], [1], [2,1], [3,2,1]]
scanr (:) [] [1, 2, 3]
-- [[1,2,3], [2,3], [3], []]
Suppose I have the following nested list:
list =
[[0, 1, 0],
[1, 9, 1],
[1, 1, 0]]
Assuming you are only given the x and y coordinate of 9. How do I use Haskell code to find out how many 1's surrounds the number 9?
Let me clarify a bit more, assume the number 9 is positioned at (0, 0).
What I am trying to do is this:
int sum = 0;
for(int i = -1; i <= 1; i++){
for(int j = -1; j <= 1; j++){
if(i == 0 || j == 0) continue;
sum += list[i][j];
}
}
The positions surrounding (0,0) are the following coordinates:
(-1, -1) (0, -1) (1, -1)
(-1, 0) (1, 0)
(-1, 1) (0, 1) (1, 1)
list = [[0,1,0],[1,9,1],[1,1,0]]
s x y = sum [list !! j !! i | i <- [x-1..x+1], j <- [y-1..y+1], i /= x || j /= y]
--s 1 1 --> 5
Note that I there is no error correction if the coordinates are at the edge. You could implement this by adding more conditions to the comprehension.
A list of lists isn't the most efficient data structure if things get bigger. You could consider vectors, or a Map (Int,Int) Int (especially if you have many zeros that could be left out).
[Edit]
Here is a slightly faster version:
s x y xss = let snip i zs = take 3 $ drop (i-1) zs
sqr = map (snip x) $ snip y xss
in sum (concat sqr) - sqr !! 1 !! 1
First we "snip out" the 3 x 3 square, then we do all calculations on it. Again, coordinates on the edges would lead to wrong results.
Edit: switched to summing surrounding 8 rather than surrounding 4
How often do you just want the surrounding count for just one entry? If you want it for all the entries, lists still perform fairly well, you just have to look at it holistically.
module Grid where
import Data.List (zipWith4)
-- given a grid A, generate grid B s.t.
-- B(x,y) = A(x-1,y-1) + A(x,y-1) + A(x+1,y-1)
-- + A(x-1,y) + A(x+1,y)
-- + A(x-1,y+1) + A(x,y+1) + A(x+1,y+1)
-- (where undefined indexes are assumed to be 0)
surrsum :: [[Int]] -> [[Int]]
surrsum rs = zipWith3 merge rs ([] : init rs') (tail rs' ++ [[]])
where -- calculate the 3 element sums on each row, so we can reuse them
rs' = flip map rs $ \xs -> zipWith3 add3 xs (0 : xs) (tail xs ++ [0])
add3 a b c = a+b+c
add4 a b c d = a+b+c+d
merge [] _ _ = []
-- add the left cell, right cell, and the 3-element sums above and below (zero-padded)
merge as bs cs = zipWith4 add4 (0 : init as) (tail as ++ [0]) (bs ++ repeat 0) (cs ++ repeat 0)
-- given a grid A, replace entries not equal to 1 with 0
onesOnly :: [[Int]] -> [[Int]]
onesOnly = map . map $ \e -> if e == 1 then 1 else 0
list :: [[Int]]
list = [[0, 1, 0]
,[1, 9, 1]
,[1, 1, 0]]
Now you can drop down to ghci to see it work:
*Grid Control.Monad> mapM_ (putStrLn . unwords . map show) list
0 1 0
1 9 1
1 1 0
*Grid Control.Monad> mapM_ (putStrLn . unwords . map show) $ onesOnly list
0 1 0
1 0 1
1 1 0
*Grid Control.Monad> mapM_ (putStrLn . unwords . map show) . surrsum $ onesOnly list
2 2 2
3 5 2
2 3 2