I came across this in the solution presented by Saurabh Kr Vats at this http://www.careercup.com/question?id=14990323
He says:
# Finally, the sequence could be "rho-shaped." In this
# case, the sequence looks something like this:
#
# x_0 -> x_1 -> ... x_k -> x_{k+1} ... -> x_{k+j}
# ^ |
# | |
# +-----------------------+
#
# That is, the sequence begins with a chain of elements that enters a cycle,
# then cycles around indefinitely. We'll denote the first element of the cycle
# that is reached in the sequence the "entry" of the cycle.
I searched online and reached cycle detection. I could see the rho shaped being formed when we reach the start/end of a cycle and try to go to an element which is not adjacent to it. I did not however understand the representation of the sequence or its usage.
It would be great if someone could explain it with an example.
It means literally in the shape of the Greek letter rho, which is "ρ". The idea is that if you map the values out as a graph, the visual representation forms this shape. You could also think of it as "d" shaped or "p" shaped. But look carefully at the font and notice that the line or stem extends slightly past the loop, while it doesn't on a rho. Rho is a better description of the shape because the loop never exits; i.e., there shouldn't be any lines leading out of the loop. That and mathematicians love Greek letters.
You have some number of values which do not repeat; these form a line or the "stem" of the "letter". The values then enter a loop or cycle, forming a circle or the "loop" of the "letter".
For example, consider the repeating decimals 7/12 (0.5833333...) and 3227/55 (5.81441441444...). If you make your sequence the digits in the number, then you can graph these out to form a rho shape. Let's look at 3227/55.
x0 = 5
x1 = 8
x2 = 1
x3 = 4
x4 = 4
x5 = 1 = x2
x6 = 4 = x3
x7 = 4 = x4
...
You can graph it like so:
5 -> 8 -> 1
^ \
/ v
4 <- 4
You can see this forms a "ρ" shape.
The comment in the code snippet looks incomplete. In context, I think that
# x_0 -> x_1 -> ... x_k -> x_{k+1} ... -> x_{k+j}
should have been
# x_0 -> x_1 -> ... x_k -> x_{k+1} ... -> x_{k+j} = x_k
which would make j the length of the cycle and x_0 -> x_1 -> ... -> x_{k-1} the "tail" of the sequence before you get to the circle that the tail is attached to.
A nice example is provided by the 3n+1 problem. This is where you start with a seed number which is a positive integer and either divide it by 2 if it is even or multiply it by 3 and add 1 if it is odd. With seed 5 this gives the sequence
5 -> 16 -> 8 -> 4 -> 2 -> 1 -> 4 -> 2 -> 1 -> ...
which can be written like
5 -> 16 -> 8 -> 4
/ \
1 <- 2
which sort of looks like a rho which has fallen over.
The Collatz Conjecture is that all seeds yield rho-shaped sequences which end up in the same cycle of length 3.
If you have a sequence that turns into a cycle then at the point where the initial sequence meets the cycle there is a value that you can get to in two ways, either from the initial sequence or from the cycle.
I don't know if this is a representative example, but suppose that the array holds {1,2,3,1,0} and you start at 0. Then you end up with 0->1->2->3->1->2->3->1... and you find that f(0)=f(3)=1
Related
Not sure if I should ask here or a different stack exchange but.
Basically I'm wondering if there is a known way to find the shortest path between two values given a number of potential transformations?
Brute force solution/example in python
from itertools import permutations, groupby
start = ["A", "B", "C", "D"]
goal = ["A", "X", "C", "Y"]
Transforms = [
(None,None,"B","D"),
("F",None,None,"Y"),
(None,"X","C",None),
(None,None,"G","Y"),
("D","X",None,None),
(None,"X",None,None)
]
def apply_transform(value, transform):
for x in range(4):
if transform[x] is None: continue
value[x] = transform[x]
perms = permutations(range(len(Transforms)))
results = []
for order in perms:
value = start.copy()
moves = 0
for o in order:
moves += 1
apply_transform(value, Transforms[o])
if value == goal:
results.append([moves, order[0:moves]])
break
# just printing sorted unique in a formated way...I'd be just picking the first one not listing all potential ones
results.sort( key=lambda x: x[0])
results = list(k for k,_ in groupby(results))
print("\n".join(f"moves {m} | {' -> '.join(str(s) for s in ms)}" for m,ms in results))
results that correctly move the start to the goal.
moves 2 | 3 -> 2
moves 3 | 0 -> 3 -> 2
moves 3 | 3 -> 5 -> 2
moves 3 | 5 -> 3 -> 2
moves 4 | 0 -> 3 -> 5 -> 2
moves 4 | 0 -> 5 -> 3 -> 2
moves 4 | 5 -> 0 -> 3 -> 2
so picking the first item in the sorted list as the lowest number of transformations. (applying transformation "3" and then transformation "2").
Obviously, this exact brute force "algorithm" can be improved by breaking out of a permutation if its already started getting longer than the lowest number of jumps... but is there a better solution to this problem I'm not seeing? Some sort of graph? Permutations aren't the best for speed but it might be the only option. Are there other small optimizations that can be done with this?
One possible optimization would be to find transformations that have to be last ones, and work your way backwards.
So, here only transformations 2 and 5 can be the last ones, and 5 is the subgroup of 2 so it can be ignored (one more optimization: ignore transformations that are parts of other transformations), and the only that remains is 2.
Now you are looking how to reach state (A, *, *, Y) using remaining transformations. Transformations 1 and 3 are the only candidates, and 3 -> 2 makes the solution.
This algorithm is a bit complicated, because it requires recursion and backtracking (if you do it the easy way, depth-first), or some queue processing (if you do it the better way, breadth-first), but it will be faster than trying all possible permutations.
Think of it as a graph. Each value is a node, and the transformations are edges. There are known algorithms for the shortest path in a graph, e. g. Dijkstra or A*.
Expected Behaviour of the algorithm
I have two strings a and b, with a being the shorter string. I would like to find the substring of b, that has the biggest similarity to a. The substring has to be of len(a), or has to be placed at the end of b.
e.g. for the following two strings:
a = "aa"
b = "bbaba"
the possible substrings of b would be
"bb"
"ba"
"ab"
"ba"
"a"
""
The edit distance is defined as amount of Insertions and Deletion. Substitutions are not possible (Insertion + Deletion has to be used instead). The similarity between the two strings is calulated according to the following equation: norm = 1 - distance / (len(a) + len(substring)).
So the substrings above would provide the following results:
"bb" -> 2 DEL + 2 INS -> 1 - 4 / 4 = 0
"ba" -> 1 DEL + 1 INS -> 1 - 2 / 4 = 0.5
"ab" -> 1 DEL + 1 INS -> 1 - 2 / 4 = 0.5
"ba" -> 1 DEL + 1 INS -> 1 - 2 / 4 = 0.5
"a" -> 1 INS -> 1 - 1 / 3 = 0.66
"" -> 2 INS -> 1 - 2 / 2 = 0
So the algorithm should return 0.66.
Different implementations
A similar ratio is implemented by the Python library FuzzyWuzzy in the form of fuzz.partial_ratio. It calculates the ratio in two steps:
searches for matching subsequences in the longer sequence using difflib.SequenceMatcher.get_matching_blocks
calculates the ratio for substrings of len(shorter_string) starting at the matching subsequences and returns the maximum ratio
This is really slow, so it uses python-Levenshtein for this similarity calculation when it is available. This performs the same calculation based on the Levenshtein distance, which is faster. However in edge cases the calculated matching_blocks used for the ratio calculation is completely wrong (see issue 16), which does not make it a suitable replacement, when the correctness is relevant.
Current implementation
I currently use a C++ port of difflib in combination with a fast bitparallel implementation of the Levenshtein distance with the weights insertion=1, deletion=1 and substitution=2. The current implementation can be found here:
extracting matching_blocks: matching_blocks
calculating weighted Levenshtein: weighted Levenshtein
combining them to calculate the end ratio: partial_ratio
Question
Is there a faster algorithm to calculate this kind of similarity. Requirements are:
only uses Replacement/Insertion (or gives substitutions the weight 2, which has a similar effect)
allows a gap at the beginning of the longer string
allows a gap at the end of the longer string, as long as the remaining substring does not become shorter, than the length of the shorter string.
optimally it enforces, that the substring has a similar length (when it is not in the end), so it matches the behaviour of FuzzyWuzzy, but it would be fine when it allows longer subsequences to be matched aswell: e.g. for aaba:aaa this would mean, that it is allowed to use aaba as optimal subsequence instead of aab.
I am programming a very simple game.
Given n bricks with k colors place in a circle
If a brick removed, the brick which to be adjacent to it and have same color will be remove.
For each step, player can remove only one brick (but if there are exist a brick adjacent to it and have the same color, the step will not count)
The game end iff all the bricks have been removed
How can I get the minimum steps required to reach the end of game ? (My current solution is backtracking, I am thinking about dynamic programming)
EXAMPLE:
4 bricks with 3 colors R, G, B place like this:
R G B B G R B G B R R G (R) (let number it 0, 1, 2, ...)
Remove 2 -> 3 will be removed (step = 0)
R G <B> <B> G R B G B R R G
Remove 0 (step = 1)
<R> G * * G R B G B R R G
Remove 4 -> 1, 11 will be removed (step = 1)
* <G> * * <G> R B G B R R <G>
Remove 10 -> 9, 5 will be removed (step = 1)
* * * * * <R> B G B <R> <R> *
Remove 7 (step = 2)
* * * * * * B <G> B * * *
Remove 8 -> 6 removed -> end game, step = 2, minimal
* * * * * * <B> * <B> * * *
Really sorry for my English
Where is a solution with O(N3) complexity.
A dynamic programing. To understand how it works, and that it does, consider some sequence removing all the blocks. Now let us mark all the consequent blocks, removed together at single step. We will mark them on the initial circle. Each step can be marked as a segment of blocks of the same color (with all different blocks inside removed earlier). Below is such picture for your example:
initial: RGBBGRBGBRRG
step 1: BB
step 2: R
step 3: -G--G G
step 4: -----R RR-
step 5: ------B B---
step 6: G
Each of 'segments' are either not intersecting, or earlier one is completely inside later one. Thus, there is a way to break circle at some point. In your example it can be done between blocks 5 and 6 (or 6 and 7 also).
Now you can see the structure of solution - we must know the minimum number of steps to completely remove some continuous segment of blocks, not the circle of blocks. To do so we will have a dynamic programming F(i,j)="minumum number of steps needed to completely remove blocks from i to j". Note, that there may be j < i, which means that segment goes over the edge in the initial blocks (like step 5 on the picture above). If we can calculate F the answer will be minimum from all F(i, (i+n-1)%n) for i=0..n-1.
The base is quite obvious, empty segment (j == i-1) requires 0 steps, one block segment (i==j) requires 1 step.
The rest is harder. Consider the first block in the segment.
It is a beginning of some segment of blocks removed at some step. It must end somewhere at the block of the same color. Thus, we have:
F(i,j) = min{G(i,t)+F(t+1,j) }, i<=t <= j, blocks t and i have the same color
Here, G(i,j) is another dynamic programming, giving answer to "how many steps are required to remove all blocks from i to j, removing blocks i and j together at the last step". Remember, blocks are in line, not in circle here.
We try t as the end of segment, and thus we need G(i,t) steps to remove all these blocks. And we need another F(t+1,j) steps to remove all other blocks.
G has the same base, as F. Now look back at the picture above. The last step in the segment may consist not only of two blocks i and j (like step 3). It may have some intermediate blocks. And we will try every possible intermediate block:
G(i,j) = min{F(i+1, t-1)+G(t, j)}, i < t <= j, blocks t and i have the same color.
What is happening here? We consider block t to be the next in the line of last removed blocks. To do so, we first have to completely remove all blocks between i and t. It requires F(i+1, t-1) steps. Then we will count, how many steps we will need to remove all blocks from t to j, while corner blocks are removed last. It requires G(t, j) steps. Now block i can be removed for free, because it is adjacent to block t, and can be removed together with it at the last step. Note, how t may be equal to the j. Thus we can cover moves with only two removed blocks.
This solution requires O(N2) memory and O(N3) time.
Easiest way to implement it would be lazy dynamic programming (using recursive functions with memorization of an answer).
If you need also the sequence of steps, it is a bit harder. Each function F and G should also store the intermediate variable t value, which gives the minimum answer. Then you can reconstruct the steps using another recursive function, which will mirror F and G computation using only stored value of 't'. This way you will get all the segments, now you can output them from smallest to largest.
Edit:
Note, because j can be less than i inside F and G, you should be careful. It is not that i <= t <= j it is what t starts from i and increases until it reaches j (it may run over the end and turn to 0 from n-1). The similar for i < t <= j.
Also there is no way to pass an empty segment for the function, therefore there should not be base for j==i-1. Instead you should not call F and G in case if there is no blocks there to remove.
Let CFG G be:
S −→ AB|BA|AC|BD|EE
A −→ a
B −→ b
C −→ EB
D −→ EA
E −→ AB|BA|AC|BD|EE
How do I use the CYK algorithm to determine if the string aabbab is part of the language?
This is the pseudo code I have in my notes:
for i in 1 .. n
V[i,1] = { A | A -> x[i] }
for j in 2..n
for i in 1 .. n-j+1
{
V[i,j] = phi
for k in 1 .. j-1
V[i,j] = V[i,j] union { A | A -> BC where B in V[i,k]
and C in V[i+k,j-k]}
}
But I am not understanding how the answer got to be in an upside down triangular shape.
For example,
V[i,j] i
1(b) 2(a) 3(a) 4(b) 5(a)
1 B A,C A,C B A,C
2 S,A B S,C S,A
j
3 phi B B
4 phi S,A,C
5 S,A,C
^
|_ accept
The pseudocode[*] describes how to apply the algorithm to create the chart.
The [i, j] pair refers to a substring of the input that starts at the ith symbol and extends for j symbols. So [2, 3] refers to a 3-symbol substring, starting at symbol 2. If your input is baaba, then [2, 3] refers to the aab in the middle. (The indexes are 1-based, not 0-based.)
The chart forms a triangle because you can't have a substring that's longer than the input. If the input is 5 symbols long, then you can have a value in [1, 5], but you can't have [2, 5] because that wouldn't refer to a substring anymore. So each row is one box shorter than the row before it, forming the triangle.
V[i, j] refers to a box in the chart. Each box is the set of non-terminals that may have produced the substring described by [i, j].
The algorithm relies on the grammar being in Chomsky Normal Form. In CNF, the right side of each production is either one terminal symbol or two non-terminal symbols. (There's another algorithm that can transform a context-free grammar into CNF.)
Basically, you start with all the 1-symbol substrings of the input. The first loop in your pseudocode fills out the top row (j == 1) of your chart. It looks at all the productions in the grammar, and, if the right side of a production corresponds to that symbol, then the non-terminal on the left side of that production is added to the set V[i, 1]. (Your example seems to have some bogus entries in the first row. The {A, C} sets should be just {A}.)
The algorithm then proceeds through the rest of the rows, looking for all the possible productions that can produce the corresponding substring. For each possible way to split the current substring into two, it looks for a corresponding production. This involves combining pairs of non-terminals from certain boxes on previous rows and checking if there are any productions that produce that pair, thus building a set of non-terminals for that box.
If the box in the last row ends up with a set that contains the start symbol, then the input is valid according to the grammar. Intuitively, it says that the start symbol is a valid production for making the substring that starts at the first symbol and proceeds for the entire length.
[*] It looks like the pseudocode shown in the question contains some transcription errors. You'll want to consult an authoritative source to get the details right.
Several years ago I took an algorithms course where we were giving the following problem (or one like it):
There is a building of n floors with an elevator that can only go up 2 floors at a time and down 3 floors at a time. Using dynamic programming write a function that will compute the number of steps it takes the elevator to get from floor i to floor j.
This is obviously easy using a stateful approach, you create an array n elements long and fill it up with the values. You could even use a technically non-stateful approach that involves accumulating a result as recursively passing it around. My question is how to do this in a non-stateful manner by using lazy evaluation and tying the knot.
I think I've devised the correct mathematical formula:
where i+2 and i-3 are within the allowed values.
Unfortunately I can't get it to terminate. If I put the i+2 case first and then choose an even floor I can get it to evaluate the even floors below the target level but that's it. I suspect that it shoots straight to the highest even floor for everything else, drops 3 levels, then repeats, forever oscillating between the top few floors.
So it's probably exploring the infinite space (or finite but with loops) in a depth first manner. I can't think of how to explore the space in a breadth first fashion without using a whole lot of data structures in between that effectively mimic a stateful approach.
Although this simple problem is disappointingly difficult I suspect that having seen a solution in 1 dimension I might be able to make it work for a 2 dimensional variation of the problem.
EDIT: A lot of the answers tried to solve the problem in a different way. The problem itself isn't interesting to me, the question is about the method used. Chaosmatter's approach of creating a minimal function which can compare potentially infinite numbers is possibly a step in the right direction. Unfortunately if I try to create a list representing a building with 100 floors the result takes too long to compute, since the solutions to sub problems are not reused.
I made an attempt to use a self-referencing data structure but it doesn't terminate, there is some kind of infinite loop going on. I'll post my code so you can understand what it is I'm going for. I'll change the accepted answer if someone can actually solve the problem using dynamic programming on a self-referential data structure using laziness to avoid computing things more than once.
levels = go [0..10]
where
go [] = []
go (x:xs) = minimum
[ if i == 7
then 0
else 1 + levels !! i
| i <- filter (\n -> n >= 0 && n <= 10) [x+2,x-3] ]
: go xs
You can see how 1 + levels !! i tries to reference the previously calculated result and how filter (\n -> n >= 0 && n <= 10) [x+2,x-3] tries to limit the values of i to valid ones. As I said, this doesn't actually work, it simply demonstrates the method by which I want to see this problem solved. Other ways of solving it are not interesting to me.
Since you're trying to solve this in two dimensions, and for other problems than the one described, let's explore some more general solutions. We are trying to solve the shortest path problem on directed graphs.
Our representation of a graph is currently something like a -> [a], where the function returns the vertices reachable from the input. Any implementation will additionally require that we can compare to see if two vertices are the same, so we'll need Eq a.
The following graph is problematic, and introduces almost all of the difficulty in solving the problem in general:
problematic 1 = [2]
problematic 2 = [3]
problematic 3 = [2]
problematic 4 = []
When trying to reach 4 from 1, there are is a cycle involving 2 and 3 that must be detected to determine that there is no path from 1 to 4.
Breadth-first search
The algorithm Will presented has, if applied to the general problem for finite graphs, worst case performance that is unbounded in both time and space. We can modify his solution to attack the general problem for graphs containing only finite paths and finite cycles by adding cycle detection. Both his original solution and this modification will find finite paths even in infinite graphs, but neither is able to reliably determine that there is no path between two vertices in an infinite graph.
acyclicPaths :: (Eq a) => (a->[a]) -> a -> a -> [[a]]
acyclicPaths steps i j = map (tail . reverse) . filter ((== j).head) $ queue
where
queue = [[i]] ++ gen 1 queue
gen d _ | d <= 0 = []
gen d (visited:t) = let r = filter ((flip notElem) visited) . steps . head $ visited
in map (:visited) r ++ gen (d+length r-1) t
shortestPath :: (Eq a) => (a->[a]) -> a -> a -> Maybe [a]
shortestPath succs i j = listToMaybe (acyclicPaths succs i j)
Reusing the step function from Will's answer as the definition of your example problem, we could get the length of the shortest path from floor 4 to 5 of an 11 story building by fmap length $ shortestPath (step 11) 4 5. This returns Just 3.
Let's consider a finite graph with v vertices and e edges. A graph with v vertices and e edges can be described by an input of size n ~ O(v+e). The worst case graph for this algorithm is to have one unreachable vertex, j, and the remaining vertexes and edges devoted to creating the largest number of acyclic paths starting at i. This is probably something like a clique containing all the vertices that aren't i or j, with edges from i to every other vertex that isn't j. The number of vertices in a clique with e edges is O(e^(1/2)), so this graph has e ~ O(n), v ~ O(n^(1/2)). This graph would have O((n^(1/2))!) paths to explore before determining that j is unreachable.
The memory required by this function for this case is O((n^(1/2))!), since it only requires a constant increase in the queue for each path.
The time required by this function for this case is O((n^(1/2))! * n^(1/2)). Each time it expands a path, it must check that the new node isn't already in the path, which takes O(v) ~ O(n^(1/2)) time. This could be improved to O(log (n^(1/2))) if we had Ord a and used a Set a or similar structure to store the visited vertices.
For non-finite graphs, this function should only fail to terminate exactly when there doesn't exists a finite path from i to j but there does exist a non-finite path from i to j.
Dynamic Programming
A dynamic programming solution doesn't generalize in the same way; let's explore why.
To start with, we'll adapt chaosmasttter's solution to have the same interface as our breadth-first search solution:
instance Show Natural where
show = show . toNum
infinity = Next infinity
shortestPath' :: (Eq a) => (a->[a]) -> a -> a -> Natural
shortestPath' steps i j = go i
where
go i | i == j = Zero
| otherwise = Next . foldr minimal infinity . map go . steps $ i
This works nicely for the elevator problem, shortestPath' (step 11) 4 5 is 3. Unfortunately, for our problematic problem, shortestPath' problematic 1 4 overflows the stack. If we add a bit more code for Natural numbers:
fromInt :: Int -> Natural
fromInt x = (iterate Next Zero) !! x
instance Eq Natural where
Zero == Zero = True
(Next a) == (Next b) = a == b
_ == _ = False
instance Ord Natural where
compare Zero Zero = EQ
compare Zero _ = LT
compare _ Zero = GT
compare (Next a) (Next b) = compare a b
we can ask if the shortest path is shorter than some upper bound. In my opinion, this really shows off what's happening with lazy evaluation. problematic 1 4 < fromInt 100 is False and problematic 1 4 > fromInt 100 is True.
Next, to explore dynamic programming, we'll need to introduce some dynamic programming. Since we will build a table of the solutions to all of the sub-problems, we will need to know the possible values that the vertices can take. This gives us a slightly different interface:
shortestPath'' :: (Ix a) => (a->[a]) -> (a, a) -> a -> a -> Natural
shortestPath'' steps bounds i j = go i
where
go i = lookupTable ! i
lookupTable = buildTable bounds go2
go2 i | i == j = Zero
| otherwise = Next . foldr minimal infinity . map go . steps $ i
-- A utility function that makes memoizing things easier
buildTable :: (Ix i) => (i, i) -> (i -> e) -> Array i e
buildTable bounds f = array bounds . map (\x -> (x, f x)) $ range bounds
We can use this like shortestPath'' (step 11) (1,11) 4 5 or shortestPath'' problematic (1,4) 1 4 < fromInt 100. This still can't detect cycles...
Dynamic programming and cycle detection
The cycle detection is problematic for dynamic programming, because the sub-problems aren't the same when they are approached from different paths. Consider a variant of our problematic problem.
problematic' 1 = [2, 3]
problematic' 2 = [3]
problematic' 3 = [2]
problematic' 4 = []
If we are trying to get from 1 to 4, we have two options:
go to 2 and take the shortest path from 2 to 4
go to 3 and take the shortest path from 3 to 4
If we choose to explore 2, we will be faced with the following option:
go to 3 and take the shortest path from 3 to 4
We want to combine the two explorations of the shortest path from 3 to 4 into the same entry in the table. If we want to avoid cycles, this is really something slightly more subtle. The problems we faced were really:
go to 2 and take the shortest path from 2 to 4 that doesn't visit 1
go to 3 and take the shortest path from 3 to 4 that doesn't visit 1
After choosing 2
go to 3 and take the shortest path from 3 to 4 that doesn't visit 1 or 2
These two questions about how to get from 3 to 4 have two slightly different answers. They are two different sub-problems which can't fit in the same spot in a table. Answering the first question eventually requires determining that you can't get to 4 from 2. Answering the second question is straightforward.
We could make a bunch of tables for each possible set of previously visited vertices, but that doesn't sound very efficient. I've almost convinced myself that we can't do reach-ability as a dynamic programming problem using only laziness.
Breadth-first search redux
While working on a dynamic programming solution with reach-ability or cycle detection, I realized that once we have seen a node in the options, no later path visiting that node can ever be optimal, whether or not we follow that node. If we reconsider problematic':
If we are trying to get from 1 to 4, we have two options:
go to 2 and take the shortest path from 2 to 4 without visiting 1, 2, or 3
go to 3 and take the shortest path from 3 to 4 without visiting 1, 2, or 3
This gives us an algorithm to find the length of the shortest path quite easily:
-- Vertices first reachable in each generation
generations :: (Ord a) => (a->[a]) -> a -> [Set.Set a]
generations steps i = takeWhile (not . Set.null) $ Set.singleton i: go (Set.singleton i) (Set.singleton i)
where go seen previouslyNovel = let reachable = Set.fromList (Set.toList previouslyNovel >>= steps)
novel = reachable `Set.difference` seen
nowSeen = reachable `Set.union` seen
in novel:go nowSeen novel
lengthShortestPath :: (Ord a) => (a->[a]) -> a -> a -> Maybe Int
lengthShortestPath steps i j = findIndex (Set.member j) $ generations steps i
As expected, lengthShortestPath (step 11) 4 5 is Just 3 and lengthShortestPath problematic 1 4 is Nothing.
In the worst case, generations requires space that is O(v*log v), and time that is O(v*e*log v).
The problem is that min needs to fully evaluate both calls to f,
so if one of them loops infinitly min will never return.
So you have to create a new type, encoding that the number returned by f is Zero or a Successor of Zero.
data Natural = Next Natural
| Zero
toNum :: Num n => Natural -> n
toNum Zero = 0
toNum (Next n) = 1 + (toNum n)
minimal :: Natural -> Natural -> Natural
minimal Zero _ = Zero
minimal _ Zero = Zero
minimal (Next a) (Next b) = Next $ minimal a b
f i j | i == j = Zero
| otherwise = Next $ minimal (f l j) (f r j)
where l = i + 2
r = i - 3
This code actually works.
standing on the floor i of n-story building, find minimal number of steps it takes to get to the floor j, where
step n i = [i-3 | i-3 > 0] ++ [i+2 | i+2 <= n]
thus we have a tree. we need to search it in breadth-first fashion until we get a node holding the value j. its depth is the number of steps. we build a queue, carrying the depth levels,
solution n i j = case dropWhile ((/= j).snd) queue
of [] -> Nothing
((k,_):_) -> Just k
where
queue = [(0,i)] ++ gen 1 queue
The function gen d p takes its input p from d notches back from its production point along the output queue:
gen d _ | d <= 0 = []
gen d ((k,i1):t) = let r = step n i1
in map (k+1 ,) r ++ gen (d+length r-1) t
Uses TupleSections. There's no knot tying here, just corecursion, i.e. (optimistic) forward production and frugal exploration. Works fine without knot tying because we only look for the first solution. If we were searching for several of them, then we'd need to eliminate the cycles somehow.
see also: https://en.wikipedia.org/wiki/Corecursion#Discussion
With the cycle detection:
solutionCD1 n i j = case dropWhile ((/= j).snd) queue
of [] -> Nothing
((k,_):_) -> Just k
where
step n i visited = [i2 | let i2=i-3, not $ elem i2 visited, i2 > 0]
++ [i2 | let i2=i+2, not $ elem i2 visited, i2 <=n]
queue = [(0,i)] ++ gen 1 queue [i]
gen d _ _ | d <= 0 = []
gen d ((k,i1):t) visited = let r = step n i1 visited
in map (k+1 ,) r ++
gen (d+length r-1) t (r++visited)
e.g. solution CD1 100 100 7 runs instantly, producing Just 31. The visited list is pretty much a copy of the instantiated prefix of the queue itself. It could be maintained as a Map, to improve time complexity (as it is, sol 10000 10000 7 => Just 3331 takes 1.27 secs on Ideone).
Some explanations seem to be in order.
First, there's nothing 2D about your problem, because the target floor j is fixed.
What you seem to want is memoization, as your latest edit indicates. Memoization is useful for recursive solutions; your function is indeed recursive - analyzing its argument into sub-cases, synthetizing its result from results of calling itself on sub-cases (here, i+2 and i-3) which are closer to the base case (here, i==j).
Because arithmetics is strict, your formula is divergent in the presence of any infinite path in the tree of steps (going from floor to floor). The answer by chaosmasttter, by using lazy arithmetics instead, turns it automagically into a breadth-first search algorithm which is divergent only if there's no finite paths in the tree, exactly like my first solution above (save for the fact that it's not checking for out-of-bounds indices). But it is still recursive, so indeed memoization is called for.
The usual way to approach it first, is to introduce sharing by "going through a list" (inefficient, because of sequential access; for efficient memoization solutions see hackage):
f n i j = g i
where
gs = map g [0..n] -- floors 1,...,n (0 is unused)
g i | i == j = Zero
| r > n = Next (gs !! l) -- assuming there's enough floors in the building
| l < 1 = Next (gs !! r)
| otherwise = Next $ minimal (gs !! l) (gs !! r)
where r = i + 2
l = i - 3
not tested.
My solution is corecursive. It needs no memoization (just needs to be careful with the duplicates), because it is generative, like the dynamic programming is too. It proceeds away from its starting case, i.e. the starting floor. An external accessor chooses the appropriate generated result.
It does tie a knot - it defines queue by using it - queue is on both sides of the equation. I consider it the simpler case of knot tying, because it is just about accessing the previously generated values, in disguise.
The knot tying of the 2nd kind, the more complicated one, is usually about putting some yet-undefined value in some data structure and returning it to be defined by some later portion of the code (like e.g. a back-link pointer in doubly-linked circular list); this is indeed not what my1 code is doing. What it does do is generating a queue, adding at its end and "removing" from its front; in the end it's just a difference list technique of Prolog, the open-ended list with its end pointer maintained and updated, the top-down list building of tail recursion modulo cons - all the same things conceptually. First described (though not named) in 1974, AFAIK.
1 based entirely on the code from Wikipedia.
Others have answered your direct question about dynamic programming. However, for this kind of problem I think the greedy approach works the best. It's implementation is very straightforward.
f i j :: Int -> Int -> Int
f i j = snd $ until (\(i,_) -> i == j)
(\(i,x) -> (i + if i < j then 2 else (-3),x+1))
(i,0)