Jump to content
BrainDen.com - Brain Teasers
  • 0

optimal game strat


phil1882
 Share

Question

in this two player game, each  player secretly picks two  numbers, one of  which is his own starting number and the other is his opponents goal number. numbers are allowed to be any integer value between 1 and 256. then both players reveal the numbers, and may use addition, subtraction, multiplication, and division, to try to get to the  goal number using only numbers they generate from their starting value.

for example, player A may pick start 36 goal 47, and player B may pick start 123 goal 123.

player A does 36/36 for 1. player B does 123/123 for 1.

player A does 1+1 for 2. player B does 1+1 for 2.

player A does 1+2 for 3. player B does 1+2 for 3.

player A does 36*3 for 104. player B does 123/3 for 41.

player A does 36/2 for 18. player B does 41+3 for 44.

player A does 104+18 for 126. player B does 44 +3 for 47. therefore player B wins.

note ties are possible if both players get it  in the same number of operations.

so you know the drill, whats the best starting value and worst ending value, assuming you don't know what your opponent is going to pick?

Link to comment
Share on other sites

Recommended Posts

  • 0

After further study, I realized that the first path to a goal generated may not be the shortest path. It needs to keep generating goals until no new or shorter paths are found. It seems this doesn't happen all that often, so it hardly affects the runtime.

 

Eliminating some of the low level structure, the full matrix including paths can be saved, at least as high as 256. Judging by the memory usage, it could probably go a bit higher.

 

Here's the results I have for 256. Hopefully they pass all of plasmid's tests this time.

  Reveal hidden contents

So, not too bad at 7.5 minutes.

 

Here's the latest code.

  Reveal hidden contents

Link to comment
Share on other sites

  • 0

Nice problem.

 

Are you asking for the starting and ending values to chose, that would maximize your chance to win?

By this question I'm trying to clarify "worst ending value."

 

Also, by your example, can we conclude that only two numbers can be combined on each turn?

 

Thanks.

 

  Reveal hidden contents
One's starting number should be factor-rich, like 30 or 210, and opponent's number should be the opposite - a prime, and probably a large prime, like 251.
Link to comment
Share on other sites

  • 0

It looks like this will be more of a programming exercise than anything.

And it looks like it won't be all that amenable to a simple greedy algorithm. (It would probably be solved with some sort of greedy algorithm, but not the simple one I'm thinking of.)

 

For example, getting from 1 to 7 would involve

1+1=2

2*2=4

2+1=3

4+3=7

 

It takes two steps to generate 3 (1+1=2, 2+1=3) and two steps to generate 4 (1+1=2, 2+2=4).

But it does not take [two steps to make 3] + [two steps to make 4] + [a step to combine 3 and 4] = 5 steps to generate 7 because the 1+1=2 is shared by the generation of 3 and 4.

Link to comment
Share on other sites

  • 0

Agree. What it seems to boil down to is constructing a 255 x 255 matrix, looking for the smallest number in each column and selecting the row having the largest minimum, for the second answer, and the column through the smallest maximum for the first part. That's a lot of computing, once an algorithm is found to get from any A to any B in the fewest moves.

Link to comment
Share on other sites

  • 0

  Reveal hidden contents

a start number should be 210 which is factor-rich( 1 to 7)


while the goal number should be a prime number which has the biggest difference between it and the two prime numbers before and after it , and this number is 127.
because,
131-127=4 steps
127-113=14 steps
so to win he should choose 210 as a start number, and 127 as a goal number.
Link to comment
Share on other sites

  • 0

Perl's dynamic arrays make things easy to program (relatively). This program works if you have a small range that you're working over -- if the maximum value of the numbers is 10 instead of 255 -- but would be horribly inefficient if you wanted to calculate it for 255. It does give an algorithm that would work in principle, though. If there were an easy way of eliminating redundant arrays and repeated terms within arrays (which I imagine there are a bunch of) then it might be feasible for 255.

  Reveal hidden contents

  Reveal hidden contents

From 1 to 1 took 0 moves

From 1 to 2 took 1 moves

From 1 to 3 took 2 moves

From 1 to 4 took 2 moves

From 1 to 5 took 3 moves

From 1 to 6 took 3 moves

From 1 to 7 took 4 moves

From 1 to 8 took 3 moves

From 1 to 9 took 3 moves

From 1 to 10 took 4 moves

From 2 to 1 took 1 moves

From 2 to 2 took 0 moves

From 2 to 3 took 2 moves

From 2 to 4 took 1 moves

From 2 to 5 took 3 moves

From 2 to 6 took 2 moves

From 2 to 7 took 4 moves

From 2 to 8 took 2 moves

From 2 to 9 took 3 moves

From 2 to 10 took 3 moves

From 3 to 1 took 1 moves

From 3 to 2 took 2 moves

From 3 to 3 took 0 moves

From 3 to 4 took 2 moves

From 3 to 5 took 3 moves

From 3 to 6 took 1 moves

From 3 to 7 took 3 moves

From 3 to 8 took 3 moves

From 3 to 9 took 1 moves

From 3 to 10 took 3 moves

From 4 to 1 took 1 moves

From 4 to 2 took 2 moves

From 4 to 3 took 2 moves

From 4 to 4 took 0 moves

From 4 to 5 took 2 moves

From 4 to 6 took 3 moves

From 4 to 7 took 3 moves

From 4 to 8 took 1 moves

From 4 to 9 took 3 moves

From 4 to 10 took 3 moves

From 5 to 1 took 1 moves

From 5 to 2 took 2 moves

From 5 to 3 took 3 moves

From 5 to 4 took 2 moves

From 5 to 5 took 0 moves

From 5 to 6 took 2 moves

From 5 to 7 took 3 moves

From 5 to 8 took 3 moves

From 5 to 9 took 3 moves

From 5 to 10 took 1 moves

From 6 to 1 took 1 moves

From 6 to 2 took 2 moves

From 6 to 3 took 3 moves

From 6 to 4 took 3 moves

From 6 to 5 took 2 moves

From 6 to 6 took 0 moves

From 6 to 7 took 2 moves

From 6 to 8 took 3 moves

From 6 to 9 took 4 moves

From 6 to 10 took 3 moves

From 7 to 1 took 1 moves

From 7 to 2 took 2 moves

From 7 to 3 took 3 moves

From 7 to 4 took 3 moves

From 7 to 5 took 3 moves

From 7 to 6 took 2 moves

From 7 to 7 took 0 moves

From 7 to 8 took 2 moves

From 7 to 9 took 3 moves

From 7 to 10 took 4 moves

From 8 to 1 took 1 moves

From 8 to 2 took 2 moves

From 8 to 3 took 3 moves

From 8 to 4 took 3 moves

From 8 to 5 took 4 moves

From 8 to 6 took 3 moves

From 8 to 7 took 2 moves

From 8 to 8 took 0 moves

From 8 to 9 took 2 moves

From 8 to 10 took 3 moves

From 9 to 1 took 1 moves

From 9 to 2 took 2 moves

From 9 to 3 took 3 moves

From 9 to 4 took 3 moves

From 9 to 5 took 4 moves

From 9 to 6 took 4 moves

From 9 to 7 took 3 moves

From 9 to 8 took 2 moves

From 9 to 9 took 0 moves

From 9 to 10 took 2 moves

From 10 to 1 took 1 moves

From 10 to 2 took 2 moves

From 10 to 3 took 3 moves

From 10 to 4 took 3 moves

From 10 to 5 took 3 moves

From 10 to 6 took 4 moves

From 10 to 7 took 4 moves

From 10 to 8 took 3 moves

From 10 to 9 took 2 moves

From 10 to 10 took 0 moves

Edited by plasmid
Link to comment
Share on other sites

  • 0

I got the code a little more efficient (thanks to the magical ~~ operator in perl) so it could work with a max value of 30 instead of 10, running for a matter of hours, but it's still far less than the 255 in the OP.

The answer was surprising.

  Reveal hidden contents

This is a matrix where the row number is the number you're starting from, and the column number is the number you're trying to reach, and the number in that cell is the number of moves needed to get there. The starting point with the fewest maximum number of moves needed is 7, which was surprising. The ending point that takes the most moves to reach (based on just taking the average of each column) is not surprising -- primes take a lot and the larger primes take more than the smaller ones.

  Reveal hidden contents

Link to comment
Share on other sites

  • 0

  Reveal hidden contents

along with plasmid's findings, am thinking the factor rich approach may not be optimal as it takes a fair amount of steps to get one of a factor pair. what may be best are powers of two. using 8 as the starting number, one can generate all numbers between 1 and 64 in five steps except 53 and 59 which can be done in six steps (one of which can be 8 x 8). from there 65 - 128 can be constructed in at most two more steps: 8 x 8 and 64 + (1-64). Then 129-256 can be constructed similarly: 64 + 64 and 128 + (1-128) for a maximum number of nine steps. some of the 129-256 can probably be reduced to fewer steps but thinking not all. have not run the spreadsheet past 64.

though certainly have no clue as to proving this as best or an analytical way to go about finding the best starting number without a brute force exhaustive search.

Link to comment
Share on other sites

  • 0

Just some random analysis...

 

Any choice of start and goal can be a winner.

 

If we have the matrix of shortest path lengths from each start to each goal, is it not the case that we would use some game theory, and randomly choose our start and goal values based on this matrix?

 

For instance, if choosing a starting value of 23 has a 1% chance of winning, and 24 has a 0.1% chance of winning, we should choose 23 ten times more often than 24. But we should still choose 24 sometimes, to keep the opponent honest.

 

While it might be interesting to note what the initial matrix looks like (what are good starting numbers and good goals), it seems the best approach is to iteratively generate start and goal vectors.

Link to comment
Share on other sites

  • 0

I wrote a Perl program. These results took about 5 minutes:

 

  Reveal hidden contents

Best starts have 7 worst case steps:
2 => 89, 7 steps
3 => 139, 7 steps
4 => 139, 7 steps
5 => 141, 7 steps
6 => 233, 7 steps
7 => 165, 7 steps
8 => 87, 7 steps
9 => 95, 7 steps
10 => 107, 7 steps
11 => 115, 7 steps
12 => 115, 7 steps
13 => 137, 7 steps
14 => 163, 7 steps
17 => 143, 7 steps
18 => 155, 7 steps
19 => 107, 7 steps
20 => 173, 7 steps
21 => 161, 7 steps
22 => 75, 7 steps
23 => 124, 7 steps
24 => 129, 7 steps
25 => 165, 7 steps
26 => 201, 7 steps
27 => 71, 7 steps
28 => 67, 7 steps
29 => 69, 7 steps
30 => 101, 7 steps
31 => 73, 7 steps
32 => 53, 7 steps
33 => 86, 7 steps
34 => 45, 7 steps
35 => 59, 7 steps
36 => 86, 7 steps
38 => 62, 7 steps
39 => 61, 7 steps
40 => 26, 7 steps
41 => 52, 7 steps
42 => 133, 7 steps
43 => 67, 7 steps
45 => 71, 7 steps
51 => 23, 7 steps
53 => 76, 7 steps
54 => 87, 7 steps

Worst goals have 6.5 mean steps:
247 => 6.50 mean steps
233 => 6.49 mean steps
235 => 6.46 mean steps
251 => 6.45 mean steps
137 => 6.44 mean steps
139 => 6.42 mean steps
151 => 6.41 mean steps
229 => 6.41 mean steps
179 => 6.40 mean steps
149 => 6.40 mean steps
141 => 6.39 mean steps
249 => 6.39 mean steps
199 => 6.39 mean steps
173 => 6.39 mean steps
211 => 6.38 mean steps
239 => 6.38 mean steps
131 => 6.38 mean steps
237 => 6.38 mean steps
193 => 6.37 mean steps
205 => 6.37 mean steps
157 => 6.37 mean steps
253 => 6.37 mean steps
241 => 6.36 mean steps
187 => 6.36 mean steps
245 => 6.36 mean steps
191 => 6.36 mean steps
133 => 6.36 mean steps
181 => 6.35 mean steps
203 => 6.35 mean steps
167 => 6.35 mean steps
217 => 6.35 mean steps
175 => 6.34 mean steps
185 => 6.34 mean steps
197 => 6.33 mean steps
103 => 6.32 mean steps
227 => 6.32 mean steps
215 => 6.32 mean steps
201 => 6.32 mean steps
177 => 6.32 mean steps
183 => 6.32 mean steps
207 => 6.32 mean steps
134 => 6.32 mean steps
213 => 6.31 mean steps
231 => 6.31 mean steps
163 => 6.30 mean steps
223 => 6.30 mean steps
155 => 6.30 mean steps
206 => 6.30 mean steps
221 => 6.30 mean steps

 

The Perl program is below. To avoid blowing up memory, it only keeps the paths long enough to compute the worst one for each start. However, it is easily tweaked to keep the longest path for each start value. There is also a speedup by limiting paths to less than the square of the highest allowed starting value. This makes a few paths a bit longer, but doesn't seem to affect the overall results much.

 

  Reveal hidden contents

Edited by Quantum.Mechanic
Link to comment
Share on other sites

  • 0

  Reveal hidden contents

Let's assume a matrix of fewest moves from A to B for all A and all B exists.

Let's call opponent's starting and ending numbers A and B, and our starting and ending numbers C and D, respectively.

 

Keep in mind the table does not give winning percentages for our choices of C and D.

For the table to usefully guide our choice of C and D, we need to know something about A and B.

And that knowledge might simply be that we know nothing about them -- that for our purposes they're random.

 

Strategy 0:

 

Suppose we know A and B exactly.

The table gives us C and D values that will guarantee a win.

 

Alas, we don't know A and B.

 

Strategy 1:

 

Suppose we have no clue about A and B and assume they are randomly chosen.

 

In that case:

Averages of table rows give expected moves to D for each D.

Averages of table columns give expected moves from C for each C.

 

Pick the C and D with least and greatest expected moves, respectively.

That does not guarantee a win, but it gives us the highest probability of winning.

 

Strategy 2:

 

Since row and column averages differ:

Assume that those differences have guided opponents' choice of A and B.

Assume A and B are not randomly chosen, but based rather on expected moves vs. a random opponent.

 

Calculate expected moves from the appropriately weighted row and column averages.

Pick C and D, again, having the least and greatest expected moves.

 

Strategy 3:

 

Assume opponent's probability distribution is based on expected moves vs. a weighted-average opponent.

Calculate expected moves again, but now weighted by that probability distribution.

Pick C and D accordingly.

 

And so on...

 

This process might converge to a best overall choice for C and D.

 

But here's the kicker:

 

Anything we can calculate, opponent can calculate.

If opponent can anticipate our C and D, however good we think they might be,

the table will then give him values of A and B that will beat them.

 

But of course, we can find those values too, and the table then gives us values of C and D that will beat them.

 

And the problem is now seen to resemble a poker game.

 

My final answer:

 

Since the OP gives us no clue as to how opponent would play poker, we cannot anticipate his strategy.

That's another way of saying we don't know A and B -- that we may as well model them as being random.

 

That says Strategy 1 is best:

 

Pick the D that has the greatest row average and the C that has the smallest column average.

  • Upvote 1
Link to comment
Share on other sites

  • 0

I've been trying to figure out what makes your code run so much faster, and I think I can more or less follow its logic but I'm not sure about one point. If you wanted to get from a starting point of 1 to an ending point of 7, you could do that with

1+1=2

2*2=4

2+1=3

4+3=7

With the algorithm, after you get one path with

1, 2, 4

and another path with

1, 2, 3

it looks like the first of those sets wouldn't allow you to add 4 in the next round because there is already a different path to reach 4, and the second of those sets wouldn't allow you to add 3 in the next round because there is already a different path to reach 3. (This is from the next if (exists($m->{$result})); line.) I'm wondering if it would have a way of discovering that path to 7?

For the most part our algorithms seem to agree, but when I set the max size for both algorithms to 30, mine said you can go from 25 to 13 in 4 steps (from the matrix in my earlier post) while yours said that 25 to 13 took 6 steps (when I commented out the

if ($start{$s}{$STEPS} == $start{$start_best}{$STEPS}) {
and subsequent close bracket surrounding the print statement). A path with four steps is:

25/25 = 1

25+1 = 26

1+1 = 2

26/2 = 13

  • Upvote 1
Link to comment
Share on other sites

  • 0
  On 8/6/2014 at 6:21 AM, plasmid said:

I've been trying to figure out what makes your code run so much faster, and I think I can more or less follow its logic but I'm not sure about one point. If you wanted to get from a starting point of 1 to an ending point of 7, you could do that with

1+1=2

2*2=4

2+1=3

4+3=7

With the algorithm, after you get one path with

1, 2, 4

and another path with

1, 2, 3

it looks like the first of those sets wouldn't allow you to add 4 in the next round because there is already a different path to reach 4, and the second of those sets wouldn't allow you to add 3 in the next round because there is already a different path to reach 3. (This is from the next if (exists($m->{$result})); line.) I'm wondering if it would have a way of discovering that path to 7?

 

 

 

I see now that my algorithm doesn't merge paths. I'll go off and chew on that a bit, and see what I can do.

Link to comment
Share on other sites

  • 0

OK, now I've added path merging, and fixed a bug where some paths didn't progress. (Thanks plasmid for checking my work.)

 

Here's a run with 256, also printing out details for a worst start/goal pair of (195,170), and some other stats that might be interesting.

  Reveal hidden contents

Note that order is not preserved in the path listing. This can be done, but it takes more work, and is usually thrown away.

 

Here's the code, much of it just for recording info for stats.

  Reveal hidden contents

Note that it has to dump the full list of paths after each start value. Otherwise, the memory blows up.

 

I've also limited the upper end to twice the $last value. There may be a few rare results that find a shorter path via a large power, but I can't prove or disprove this. Anyone have a counter example?

Edited by Quantum.Mechanic
Link to comment
Share on other sites

  • 0

Unless I'm reading it incorrectly, under Best starts with 10 worst case steps, it seems to say that it takes 10 steps to get from 9 to 13. But that's clearly not optimal.

It isn't giving me quite the same answers when I tried running the code. I set $last to 20 and forced $start to just be 9, and it said the worst case was 9 => 14 in 9 steps. Setting $my_start and $my_goal to 9 and 14 and rearranging the operations, it seemed to have taken

9/9 = 1

9-1 = 8

1+1 = 2

9+9 = 18

18+9 = 27

27+8 = 35

18+1 = 19

19+2 = 21

35-21 = 14

It didn't pick a path like

9/9 = 1

1+1 = 2

2+2 = 4

9+4 = 13 (to get to 13 in four steps)

13+1 = 14 (to get to 14 in five steps)

My best guess about what's going on is that, when it goes through the "generate" subroutine, it just looks at all the numbers that it reached so far and finds some combination of two numbers that have been reached that leads to a number that hasn't been reached yet, without regard to the number of steps it took to reach the intervening numbers. So for example to reach 14: after one round of "generate" the algorithm will have reached 9+9 = 18 and 9/9 = 1. In the second round it could reach 9-1 = 8 and 1+1 = 2 and 18+9 = 27 and 18+1 = 19. In the third round it could reach 27+8 = 35 and 19+2 = 21. Then in the fourth round it could reach 35-21 = 14. So it only takes four rounds of the generate subroutine to reach 14 via that route which requires nine operations, as opposed to five rounds of generate to reach 14 with the five operations shown above. Essentially, it finds the path that invokes generate the fewest number of times rather than the path that uses the smallest number of operations.

Link to comment
Share on other sites

  • 0
  On 8/7/2014 at 3:12 AM, plasmid said:

My best guess about what's going on is that, when it goes through the "generate" subroutine, it just looks at all the numbers that it reached so far and finds some combination of two numbers that have been reached that leads to a number that hasn't been reached yet, without regard to the number of steps it took to reach the intervening numbers.

 

Doh! Yes, of course. With path merging, there will be longer and shorter ways to get the same result.

 

So I need to either run them all, and find the shortest; or generate in order by shortest new path length. The latter should be less space and less run time.

Link to comment
Share on other sites

  • 0
  On 8/7/2014 at 4:25 AM, bonanova said:

Does it blow memory to keep a tree structure for each starting number?

That's the same storage requirement as a 255x255 matrix.

 

Possibly not. One problem I've seen is that allowing intermediate numbers larger than the upper limit (e.g., 256) generates a lot of intermediate results of little use, which could be trimmed. And this is Perl, so the overhead for arrays and hashes is larger than you might expect. From http://perlmaven.com/how-much-memory-do-perl-variables-use, in bytes:

                          size    total_size
SCALAR                       24    24
ARRAY                        64    64
HASH                        120   120

Those are empty, unassigned variables.

 

When the structure for each start number is filled out, it could be trimmed down to the useful bits and saved long term.

Link to comment
Share on other sites

  • 0

The only potential pitfall I can think of is theoretical (at least I can't come up with a concrete example of it right now):

Suppose you start from A and need to reach D, which can be reached from B and C.

There's an optimal path from A to B in, say, four moves.

There's an optimal path from A to C in, say, five moves.

So it would look like it would take 4 moves to reach B, 5 to reach C, and therefore a total of 10 to reach D.

What if there were some number E that could be reached from A in two moves, and it would take five moves to reach B if E is included the path from A to B, and it would take six moves to reach C if E is included in the path from A to C. So E would not be included in the optimal paths to either B or C.

But suppose if you have both B and E in a set already (although such a set would never be formed by the algorithm because they don't form an optimal path), then you could reach C in two moves from {A, B, E}. Bear in mind that this still would involve a total path length from A to C of eight moves, which is far worse than the optimal five, so it would not be preserved as an optimal path.

That would create a possible path from A to D in 2 (A to E) + 4 ({A,E} to B) + 2 ({A,B,E} to C) + 1 ({A,B,C,E} to D) = 9 moves instead of 10.

I think that such a path might not be detected by this algorithm. But I'm not sure if such a scenario actually exists, or even if it's possible to prove that such a scenario cannot exist.

Link to comment
Share on other sites

  • 0
  Quote

 

Suppose you start from A and need to reach D, which can be reached from B and C.

There's an optimal path from A to B in, say, four moves.

There's an optimal path from A to C in, say, five moves.

So it would look like it would take 4 moves to reach B, 5 to reach C, and therefore a total of 10 to reach D.

I think you've left something out here, or perhaps meant something else. For pedantic clarity, I'll say this anyway:

 

You didn't say how many moves it was from B to D, or C to D. If it's the same for both, let's say 1, then A->B->D = 4+1 = 5, and A->C->D = 5+1 = 6. So the optimal is A->B->D = 5. Paths don't simply add together -- any duplicate steps only count once.

 

The rest of your statement is worth consideration. The algorithm I use is greedy -- it only keeps the shortest path to any result. But I think it is provable that if there are 2 paths A->B->D = 5 and A->C->D = 4, it will pick the latter. While it might find A->B->D first, it still checks any other paths to D, and keeps generating paths to all results until no new results are added, and no shorter paths are found.

    # This result might already exist. Keep the new one if the path is shorter.   
    if (not exists($m->{$result})                                                 
     or (scalar keys %$new_path < scalar keys %{$m->{$result}})) {                
#         print STDERR "\tAdded $expression = $result\n";                          
        $m->{$result} = $new_path;                                                
        ++$results_added;                                                         

What you are proposing is that there's some way to get to a result E through a non-optimal path to D, that's shorter than the optimal path to D, plus D->E. I'm a little rusty on my proofs, but I think this falls into the "proof by contradiction" class.

 

Earlier versions of my program didn't do this, but instead stopped when the first path to a result was found. This depended on the generation order, which wasn't necessarily generating shortest path first, instead of the path order. So if a non-optimal path to D was found, it was kept, and no further paths to D were even checked for length.

 

On the other hand, I don't think it was ever stated explicitly if all paths could only go through numbers less than or equal to the limit value. There might be some edge cases where, say, an abundant number >> limit provides a path to a goal with fewer steps than any path <= limit.

Link to comment
Share on other sites

  • 0

Checking for paths that go above the limit (last number):

 

Not allowing any intermediate results above 25:

Steps for 14 => 25 (not in order):
        13 - 2 = 11
        14 + 11 = 25
        14 - 1 = 13
        1 + 1 = 2
        14 / 14 = 1

 

Allowing intermediate results above 25:

Steps for 14 => 25 (not in order):
        14 - 1 = 13
        13 + 13 = 26
        14 / 14 = 1
        26 - 1 = 25

So this is 1 shorter.

 

On a whim, I ran it with the max intermediate step = last**2, or 625 in this case, and found this path with 4 steps:

Path above 25 for (15,10):
        15 + 15 = 30
        450 / 45 = 10
        30 + 15 = 45
        30 * 15 = 450

Limiting search to 25*2 = 50, found this path with 5 steps:

Steps for 15 => 10 (not in order):
        1 + 1 = 2
        14 - 4 = 10
        15 - 1 = 14
        2 + 2 = 4
        15 / 15 = 1

I wonder how big the search range needs to be in relation to the last number to guarantee the optimal path?

 

Link to comment
Share on other sites

  • 0

Here's a concrete example.

I tried modifying the code so it generates a matrix of steps to get from each starting point to each goal, just like the matrix I posted earlier, and runs from 1 to 30 so I could directly compare the matrices they produce. They differ at some spots, one of which is the path going from 11 to 3. For some reason it took four steps and went 11/11=1, 11+11=22, 22/11=2, 2+1=3. Obviously a shorter path would be 11/11=1, 1+1=2, 1+2=3.

Apparently there are two equally short paths from 11 to 2: {11/11=1, 1+1=2} and {11+11=22, 22/11=2}, and the algorithm ended up storing the second path as the most efficient path to get to 2. However, since it didn't store the path to 2 that creates 1 as an intermediate rather than 22, it wasn't able to discover that you could reach 3 from a path going to 2 through 1 that had a useful intermediate already generated.

  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...