I was looking up a program in Haskell that tests if a given number is prime or not.
prime :: (Integral a) => a -> Bool
prime 1 = True
prime x = and [ x `mod` y /= 0 | y <- [2..(x-1)] ]
I don't understand what is the purpose of this and in: prime x = and [.
Although this question has been answered, please allow me to add a few things:
When examining the source of and, you get:
and :: [Bool] -> Bool
and = foldr (&&) True
First thing to notice is that and takes a list of Boolean variables, and returns a single Boolean variable, and that the expression x mod y /= 0 evaluates to True or False (Hence fitting the [Bool] requirement) .
More important to notice is that foldr is a lazy-fold. So a lazy fold here is optimal because && is a semi-strict operator. Hence a lazy fold in combination with a semi-strict operator will yield a short-circuit evaluation upon encountering the first occurence of a False. Hence in the cases of actual non-prime numbers, and will avoid evaluating the entire list, consequently saving you time as a result. Don't take my word for it, define your own strict version of and if you want (using the stricter foldl):
andStrict :: [Bool] -> Bool
andStrict x = foldl (&&) True
primeStrict :: (Integral a) => a -> Bool
primeStrict x = andStrict [x `mod` y /= 0 | y <- [2..(x-1)]]
Now run:
prime 2000000000
Notice how that was fast? Now do this, but interrupt it before it crashes your memory-stack:
primeStrict 2000000000
That was obviously slower, you were able to interrupt it. This is the role of and, and that is why and was written with foldr, and hence why it was chosen for the example code you posted. Hope that helps as a supportive answer.
The expression
[x `mod` y /= 0 | y <- [2..(x - 1)]
is a list of Bools because mod x y /= 0 (prefix notation because of backtick formatting) returns a Bool. The and function just does a logical AND of every element in a list, so
and [True, False] == False
and [True, True] == True
and performs a logical and operation on all elements of a list.
Primes are only divisible by one and themselves; this means that as soon as a divisor (without a remainder) exists between 2 inclusive and your x exclusive, the number is not a prime.
The list comprehension generates a list of Boolean values that correspond to whether your x is or is not divisible by numbers from within the said range.
As soon as any of them is false (a division occurred with a zero remainder), the number is not a prime.
Consider:
x = 7
[7 % 2 /= 0 -> True, 7 % 3 /= -> True, ...]
-- now applying and
True && True && ... && True evaluates to True
and can be represented as a more general operation that can be performed on lists - a fold using logical and. Such as: and' = foldr (&&) True.
Related
Having fun working through a Haskell tutorial...
One problem posed is as you see in the subject line... this is one I'd really like to figure out, but I'm at a loss... I've used any like so:
ghci >any (==55) [15,25,35,45,55,65,75,85,95]
True
ghci >any (==55) [15,25,35,45,54,65,75,85,95]
False
ghci >all even [2,4,6,8]
True
ghci >all even [1,3,5,7,9]
False
and it seems like checking if a list element is divisible by 42 or not, should be fairly easy...
I mean, you would check if any of the numbers in the list are n `mod` 42 == 0, right?
But how do you state that in the expression? Or do you need to write a 'helper' function?
You can define function inplace:
any (\n -> n `mod` 42 == 0) [1, 2, 42]
Composing (0==) and (`mod 42`):
f :: [Integer] -> Bool
f = any ((0==).(`mod` 42))
futher reducing parenthesis noise:
f :: [Integer] -> Bool
f = any $ (0==).(`mod` 42)
Helper function:
f :: [Integer] -> Bool
f = any div42
where
div42 n = n `mod` 42 == 0
Stylistically, for this function, either way seems fine. However, say you wanted to check if any values are divisible by 42 OR 52, then utilizing composition may become more obfuscated/complex/futile. Whereas using a helper function keeps things readable: div42Or52 n = n `mod` 42 == 0 || n `mod` 52 == 0. Note, I've used a where clause above, but a let in expression or a lambda are possible alternative ways to structure helper functions.
Ultimately, its up to the developer to balance concise code with understandable code.
isOdd, isEven :: Int -> Bool
isOdd n
| n<=0 = False
| otherwise = isEven (n-1)
isEven n
| n<0 = False
| n==0 = True
| otherwise = isOdd (n-1)
I'm having trouble understanding this code,in isOdd,it only defines what is False,and then switch to isEven,so how does haskell know when is n odd?
There are two different functions here: isOdd and isEven. They are defined in terms of each other: A number is "not odd" if it is negative or zero, and "odd" if one less than that number is "even". A number is "not even" if it is negative, and "even" if it is zero or one less than that number is "odd".
It's a fairly unintuitive way to define these functions, but it has nothing to do with "execution sequence" or "evaluation order". In fact, Haskell compilers are allowed to execute any computation they want as long as it gives the correct value as a result and follows the lazy/strict semantics as specified in the Haskell Report.
A better implementation of these functions is as follows: (from the Prelude)
even, odd :: (Integral a) => a -> Bool
even n = n `rem` 2 == 0
odd = not . even
In other words, and integer-like thing is even if the remainder when you divide it by 2 is 0, and odd if it is not even.
Note: The INLINEABLE pragams in the link above are just an optimization, and can be ignored.
These functions are mutually recursive (each one can call the other one), with base cases. Lets follow an example evaluation using isOdd. First, I will start by changing the guards into the equivalent ifs for (hopefully) more clarity in this answer (though I would usually suggest using guards).
isOdd, isEven :: Int -> Bool
isOdd n =
if n <= 0
then False
else isEven (n-1)
isEven n =
if n < 0
then False
else if n == 0
then True
else isOdd (n-1)
Now, we can try stepping through an example evaluation[1]:
isOdd 3
==> if 3 <= 0 (Applying isOdd to 5 and expanding the body)
then False
else isEven (3-1)
==> isEven (3-1) (3 > 0)
==> if 2 < 0
then False
else if 2 == 0
then True
else isOdd (2-1)
==> isOdd (2-1) (4 > 0, so the first two branches aren't taken)
==> if 1 <= 0 (Applying isOdd to 1 and expanding the body)
then False
else isEven (1-1)
==> isEven 0
==> if 0 < 0
then False
else if 0 == 0
then True
else isOdd (0-1)
==> True (0 == 0, so the second branch is taken)
The intuition behind why these functions work is this: if a non-negative integer (natural number) n is greater than 0, it is odd if its predecessor (n-1) is even and it is even if its predecessor is odd. This is true since even and odd numbers alternate.
I would recommend stepping through an evaluation whenever you run into a function (or, in this case, pair of functions) that you don't understand using a small example like this.
[1]: Note for something that doesn't really matter for this question: I've slightly simplified when the expressions of the shape x-1 get reduced to the corresponding number.
this is called "mutual recursion" or "mutually recursive functions", as in the recursive functions you need to define the terminal state (or exit condition). However, your definition is not the best, here is a better alternative
isEven,isOdd :: Int -> Bool
isEven 0 = True
isEven n = isOdd (n - 1)
isOdd 0 = False
isOdd n = isEven (n - 1)
here the terminal condition is set for 0 (symmetrically) and mutual recursion will end up on one of them eventually.
Note that this is only defined for non-negative integers but not enforced with the type Int.
Your definition is not correct either but at least will terminate for negative numbers.
I need to implement to an algorithm to solve following problem in Haskell:
Given an array, check whether sum(x_0, x_1...x_k) == sum(x_k+1,...,x_n)
If the array is have NO element, then the sum is zero
1:
arr = [1]
sum([]) = 0
sum([1]) = 1
sum([]) != sum([1])
there is no such k
return False
2:
arr = [1,2,3]
sum([1,2]) == sum([3])
there is such k
return True
Here is my current implementation so far:
checkSum::[Int]->Int->Bool
checkSum [] _ = True
checkSum [x] _ = x == 0
checkSum l inx | sum(take inx l) == sum(drop inx l) = True
| inx <= length l = checkSum l (inx+1)
| otherwise = False
It works, but I need to change function prototype as following:
checkSum::[Int]->Bool
.....
Does anyone know how to implement the new function without passing index to the function?
This function comes up a surprising amount:
import Data.List (inits, tails)
splits :: [a] -> [([a],[a])]
splits xs = zip (inits xs) (tails xs)
Example usage:
ghci> splits [1,2,3]
[([],[1,2,3]),([1],[2,3]),([1,2],[3]),([1,2,3],[])]
You might also be interested in the any function.
I think you can take it from here.
A more primitive approach
checkSum :: [Int] -> Bool
checkSum a = go a 0 (sum a)
where go [] left right = left==right
go (x:xs) left right = left==right || go xs (left+x) (right-x)
at each step you're adding the element to the left value and subtracting from the right, where the initial values are 0 and sum. Terminates when equality reached at any step or when the array is exhausted.
A clever way to think about this: if we need
x[1] + ... + x[k] == x[k+1] + ... + x[n],
then we can add the left-hand side to both sides to get
(x[1] + ... + x[k]) * 2 == sum(x).
Thus, we can generate all doubled prefix sums, then look for sum(x) in them.
checkSum :: [Int] -> Bool
checkSum xs = sum xs `elem` doublePrefixSums
where doublePrefixSums = scanl (\acc x -> acc + 2*x) 0 xs
A solution using built-in functions.
Use scanl and scanr to find all the sums from the left and right.
scanl (+) 0 [1,2,3] gives you [0, 0+1, 0+1+2, 0+1+2+3]
λ> scanl (+) 0 [1,2,3]
[0,1,3,6]
scanr (+) 0 [1,2,3] gives you [1+2+3+0, 2+3+0, 3+0, 0]
λ> scanr (+) 0 [1,2,3]
[6,5,3,0]
Then zipWith to identify positions where the lists have equal elements.
λ> zipWith (==) [0,1,3,6] [6,5,3,0]
[False,False,True,False]
Then or to check if this list contains True anywhere.
λ> or [False,False,True,False]
True
The complete function:
checkSum :: [Int] -> Bool
checkSum xs = or (zipWith (==) leftSums rightSums)
where
leftSums = scanl (+) 0 xs
rightSums = scanr (+) 0 xs
(This will return True on the empty list. This seems reasonable to
me, but if you want it to be False you could write a special case for
it or just change scanr to scanr1.)
My interpretation of the question is: for some Int list x, determine ∃k::Integer. sum[x₀,…,xₖ] == sum[xₖ,…,xₙ]. Reasonably, 0 ≤ k < length x (and n = length x) because otherwise xₖ is ⊥ and we are not interested in that case.
So how would you prove that proposition? Are we interested in infinite lists? Probably not, so let us assume the list is finite. Then, if the list is finite there are also finite choices for k because 0 ≤ k < length x. A proof then can be done by checking for every choice of k. If at least one choice of k satisfies the proposition then it is true, and otherwise it is false.
When translating our method to Haskell we want to leverage existing definitions to their fullest. We can just focus on the splits of the list itself, leaving k out of the implementation. luqui's answer beautifully demonstrates this. Be aware that an abstract notation (mathematical, logical, a specification, etc) does not always indicate a good implementation.
Once we know all the splits of the list, we can sum and compare for equality. If at least one comparison succeeds then yield True, otherwise yield False.
I wrote the following to check if a number is prime:
factorsOf :: Int -> [Int]
factorsOf n = [factor | factor <- [2..sqrtOfN], n `rem` factor == 0]
where sqrtOfN = round . sqrt $ fromIntegral $ n+1
isPrime :: Int -> Bool
isPrime n
| factorsOf n == [] = True
| otherwise = False
and it works, but I noticed something weird. If I run factorsOf on a large number (say 100000001), it takes a few seconds to calculate all the factors. If I run isPrime on the same number though, it will return almost immediately if it finds a factor. Does Haskell actually keep track of the condition that a function will return to to support (I'm assuming) lazy evaluation? Thats awesome if it's true.
As noted in the comments, isPrime only needs to evaluate the result of factorsOf deeply enough to determine if it is an empty list or not. You could write isPrime more idiomatically like this:
isPrime = null . factorsOf
where null is simply
null (_:_) = False
null _ = True
Note that as soon as null can pattern match on a (:) constructor, it returns a result without evaluating the rest of the list.
This means only the factorsOf only needs to compute the first factor for isPrime to return, whereas factorsOf by itself will compute the entire list.
The basic principle of laziness is that nothing is evaluated unless it is really really needed. Really needed in your case means that the first function must return so that the other function gets its input. You can read more about Haskell's Laziness here
I'm new to Haskell, and I'm trying a bit:
isPrime :: Integer->Bool
isPrime x = ([] == [y | y<-[2..floor (sqrt x)], mod x y == 0])
I have a few questions.
Why when I try to load the .hs, WinHugs say: Instances of (Floating Integer, RealFrac Integer) required for definition of isPrime?
When the interpreter finds one element in the right set, it immediately stops or it computes all the set? I think you know what I mean.
Sorry about my english.
1) The problem is that sqrt has the type (Floating a) => a -> a, but you try to use an Integer as argument. So you have to convert your Integer first to a Floating, e.g. by writing sqrt (fromIntegral x)
2) I see no reason why == shouldn't be lazy, but for testing for an empty collection you can use the null function (which is definitely lazy, as it works on infinite lists):
isPrime :: Integer->Bool
isPrime x = null [y | y<-[2..floor (sqrt (fromIntegral x))], x `mod` y == 0]
But in order to get an more idiomatic solution, break the problem into smaller sub-problems. First, we need a list of all elements y with y*y <= x:
takeWhile (\y -> y*y <= x) [2..]
Then we need only the elements that divide x:
filter (\y -> x `mod`y == 0) (takeWhile (\y -> y*y <= x) [2..])
Then we need to check if that list is empty:
isPrime x = null (filter (\y -> x `mod`y == 0) (takeWhile (\y -> y*y <= x) [2..]))
And if this looks to lispy to you, replace some of the parens with $
isPrime x = null $ filter (\y -> x `mod` y == 0) $ takeWhile (\y -> y*y <= x) [2..]
For additional clarity you can "outsource" the lambdas:
isPrime x = null $ filter divisible $ takeWhile notTooBig [2..] where
divisible y = x `mod`y == 0
notTooBig y = y*y <= x
You can make it almost "human readable" by replacing null $ filter with not $ any:
isPrime x = not $ any divisible $ takeWhile notTooBig [2..] where
divisible y = x `mod`y == 0
notTooBig y = y*y <= x
Because sqrt has the type Floating a => a -> a. This means the input has to be a Floating type and the output will be the same type. In other words x needs to be a Floating type. However you declared x to be of type Integer, which is not a Floating type. In addition floor needs a RealFrac type, so x needs to be that as well.
The error message suggests that you fix that by making Integer a Floating type (by defining an instance Floating Integer (and the same for RealFrac).
Of course this is not the correct approach in this case. Rather you should use fromIntegral to convert x to a Real (which is an instance of Floating and RealFrac) and then give that to sqrt.
Yes. As soon as == sees that the right operand has at least one element, it knows it is not equal to [] and thus returns False.
That being said, null is a more idiomatic way to check whether a list is empty than [] ==.
Regarding the second point, it stops, for example:
[] == [x | x <- [1..]]
Returns False
Landei's solution is great, however, if you want a more efficient¹ implementation we have (thanks to BMeph):
-- list of all primes
primes :: [Integer]
primes = sieve (2 : 3 : possible [1..]) where
sieve (p : xs) = p : sieve [x | x <- xs, x `mod` p > 0]
possible (x:xs) = 6*x-1 : 6*x+1 : possible xs
isPrime :: Integer -> Bool
isPrime n = shortCircuit || (not $ any divisible $ takeWhile inRangeOf primes) where
shortCircuit = elem n [2,3] || (n < 25 && ((n-1) `mod` 6 == 0 || (n+1) `mod` 6 == 0))
divisible y = n `mod` y == 0
inRangeOf y = y * y <= n
The 'efficiency' comes from the use of constant primes. It improves the search in two ways:
The Haskell runtime could cache the results so subsequent invocations are not evaluated
It eliminates a range of numbers by logic
note that the sieve value is simply a recursive table, where says the head of
the list is prime, and adds it to it. For the rest of the lists if there is no
other value already in the list that composes the number then its also prime
possible is list of all possible primes, since all possible primes are in the
form 6*k-1 or 6*k-1 except 2 and 3
The same rule is applied for shortCircuit too to quickly bail out of calculations
Footnote by D.F.
¹ It's still a terribly inefficient way to find primes. Don't use trial division if you need primes larger than a few thousand, use a sieve instead. There are several far more efficient implementations on hackage.
I think WinHugs needs to import a module for Integer and etc... Try Int
The interpreter will not compute anything until you call e.g. isPrime 32 then it will lazily compute the expression.
PS your isPrime implementation is not the best implementation!