Basic Tree-search algorithm for searching a node (with value k) in a binary search tree.
'x' denotes the node of the binary search tree.
TREE-SEARCH (x, k)
if x= NIL or k = key[x]
then return x
if k < key[x]
then return TREE-SEARCH(left[x], k)
else return TREE-SEARCH(right[x], k)
Iterative Version:
ITERATIVE-TREE-SEARCH(x, k)
while x ≠ NIL and k ≠ key[x]
do if k < key[x]
then x ← left[x]
else x ← right[x]
return x
Shouldn't the first line (of the iterative algorithm) actually be while (x ≠ NIL OR k ≠ key[x]) instead of (while x ≠ NIL and k ≠ key[x]) ?
By the way, if you were wondering, this is from one of the famous books of Algorithm Analysis.
No, it needs to be and because otherwise you'll dereference NIL if k isn't found. Remember that while executes as long as the expression evaluates to true.
while x ≠ NIL and k ≠ key[x]
If x is NIL, then the expression x ≠ NIL and k ≠ key[x] is false, because x ≠ NIL is false. Either side of an and being false makes the whole expression false.
If or were used instead, x ≠ NIL would still be false, but you'd need to evaluate the other side — both sides of an or must be false for the or to be false. Unfortunately, evaluating the other side dereferences NIL. Ooops. Even if it weren't for that problem, k ≠ key[x] is true (because we're considering the case where k isn't found, so no key in the tree x can be k). Since one (or more) sides of the or is true, the or evaluates to true, and the loop continues forever.
In English, that while can read: while there is still tree left (x ≠ NIL) and we haven't yet found what we're looking for (k ≠ key[x]).
Related
When being left with an expression of the form ite ("a"="b") x y which involves a decidable equality between two distinct string literals, it appear that simp on its own does not allow me to reduce this expressions to y. This is in contrast to the case of ite ("a"="a") x y which is reduced to x with simp. So I find myself doing a case
analysis cases decidable.em ("a"="b") with H H and then handling one case using exfalso and dec_trivial and the other by using simp [H]. So I am able to move forward, but I was wondering if there was a more idiomatic and shorter way to achieve the same result.
Either rw [if_neg (show "a" ≠ "b", from dec_trivial)] or simp [if_neg (show "a" ≠ "b", from dec_trivial)] is the easiest way I know.
Searching for nil in a sequence using find always returns NIL.
(find nil #(a b nil c)) -> NIL
(find nil #(a b c)) -> NIL
Same thing if the sequence is a list.
However, member operates as I would expect:
(member nil '(a b nil c)) -> (NIL C)
Why was find designed to operate this way?
Note that position works as I would expect:
(position nil #(a b nil c)) -> 2
(position nil #(a b c)) -> NIL
FIND simply isn't useful if the target element is NIL. It's returning the found element, but it's indistinguishable from the not-found case. If you want to find out of a sequence has a nil, POSITION is a better option. There are many other options.
It returns nil because the result of find if the element is not in the sequence is nil. But even with member, if it is not in the sequence, it will return nil:
CL-USER> (member nil '(a b c))
NIL
CL-USER>
So technically searching for nil in a sequence will return nil with member and position if it isn't there which can be confusing of course.
CL-USER> (position nil '(a b c))
NIL
CL-USER>
The difference with position is that if nil occurs, it will return the index location of course, as you noted. Find was designed that way because it is NOT searching for an index location, but is essentially searching to match the pointer for that symbol, or return nil. That's why using position makes more sense, as you've noted.
Consider the following situation. I define a function to process a list of elements by the typical way of doing an operation on the head and recalling the function over the rest of the list. But under certain condition of the element (being negative, being a special character, ...) I change sign on the rest of the list before continuing. Like this:
f [] = []
f (x : xs)
| x >= 0 = g x : f xs
| otherwise = h x : f (opposite xs)
opposite [] = []
opposite (y : ys) = negate y : opposite ys
As opposite (opposite xs) = xs, I become to the situation of redundant opposite operations, accumulating opposite . opposite . opposite ....
It happens with other operations instead of opposite, any such that the composition with itself is the identity, like reverse.
Is it possible to overcome this situation using functors / monads / applicatives / arrows? (I don't understand well those concepts). What I would like is to be able of defining a property, or a composition pattern, like this:
opposite . opposite = id -- or, opposite (opposite y) = y
in order that the compiler or interpreter avoids to calculate the opposite of the opposite (it is possible and simple (native) in some concatenative languages).
You can solve this without any monads, since the logic is quite simple:
f g h = go False where
go _ [] = []
go b (x':xs)
| x >= 0 = g x : go b xs
| otherwise = h x : go (not b) xs
where x = (if b then negate else id) x'
The body of the go function is almost identical to that of your original f function. The only difference is that go decides whether the element should be negated or not based on the boolean value passed to it from previous calls.
Sure, just keep a bit of state telling whether to apply negate to the current element or not. Thus:
f = mapM $ \x_ -> do
x <- gets (\b -> if b then x_ else negate x_)
if x >= 0
then return (g x)
else modify not >> return (h x)
Suppose I have a following program:
foo x y = let l1 = foo 0 x
l2 = foo 0 y
in l1 + l2
This is just a simple example, but I think is enough for demonstration purposes. How could I, with each new (recursive) call to foo, change the evaluation ordering of the expression in l1 and l2? I know they are evaluated lazy inside the expression (in this case expression inside in operator) and not when they are declared, but I need a way of doing as stated, because there may be cases, where the program enters infinite loop. If this infinite recursion occurs on the secondly evaluated argument, l2, there is no problem, as l1 always gets evaluated before *l2, but if it is the other way around, that is, infinitely evaluating the l1 expression, the *l2***doesn't get a chance to evaluate. So if I could juggle between ***l1* and l2 expression evaluation on each new foo function call, the problem would be solved. Looking for a nice/general solution.
EDIT: Forgot to mantion that x or y or both might be an infinite structures (lists), and thats where the problem is.
The Problem
For a good answer, we first need a specific question. Consider that natural numbers that are either zero Z or the successor S n of another natural number n.
data Nat = Z | S Nat
zero = Z
one = S Z
two = S $ S Z
In Haskell we can also write infinite recusive data structures like
infinity = S infinity
As long as a single Nat number isn't infinity we can determine if it is even or odd.
even :: Nat -> Bool
even Z = True
even (S n) = odd n
odd :: Nat -> Bool
odd Z = False
odd (S n) = even n
For finite Nats, even is either True or False and even infinity is undefined. This is ok, but what if we wanted to check if either of two numbers is even? We can write a naïve implementation:
eitherEven :: Nat -> Nat -> Bool
eitherEven x y = even x || even y
This does quite well whenever the first argument is finite. In the following, even is any even number and odd is any odd number.
eitherEven even even == True
eitherEven even odd == True
eitherEven even infinity == True
eitherEven odd even == True
eitherEven odd odd == False
eitherEven odd infinity == undefined
But when the first argument is infinite, it doesn't return True even when the second argument is Even
eitherEven infinity even == undefined -- this should be True
eitherEven infinity odd == undefined
eitherEven infinity infinity == undefined
A simple solution
A simple solution to the problem is to alternate between testing the first argument and testing the second argument. When we call the function recursively, we swap the arguments to alternate which of the two arguments is being tested.
eitherEven :: Nat -> Nat -> Bool
eitherEven Z _ = True
eitherEven (S Z) y = even y
eitherEven (S (S x)) y = eitherEven y x
This has the desired output even when the first argument isn't finite.
> eitherEven infinity two
True
For more complicated problems where the arguments aren't treated symmetrically, you can pass a Bool flag and flip it on each step. In general you can use any state machine to keep track of where you are working.
This solution isn't very satisfying because it doesn't immediately solve what to do when we want to test if any of three numbers is even. To do so we need to write a new function.
anyEven3 :: Nat -> Nat -> Nat -> Bool
anyEven3 Z _ _ = True
anyEven3 (S Z) y z = eitherEven y z
anyEven3 (S (S x)) y z = anyEven3 y z x
We put x at the end because we want to try both y and z before trying x again. We're making a queue. If we can prove that the first thing in the queue produces a result, True, we are done. If we can prove the first thing in the queue doesn't produce a result, we remove it from the queue and use a version that works on a smaller set of inputs. If we can't decide the result for the first thing in the queue, we put it at the end. The same pattern can be seen in eitherEven which takes two arguments and even in even which takes only one argument.
anyEven :: [Nat] -> Bool
anyEven = go []
where
go [] [] = False
go r [] = go [] (reverse r)
go r ( Z :_ ) = True
go r ( S Z :ns) = go r ns
go r ((S (S x)):ns) = go (x:r) ns
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!