2048 puzzle

[cmhardw]

But isn't a merge: "When two tiles combine together to form the next tile in the sequence?"
Your calculations seem to disagree with this definition.

Please help me to see how. Stefan counts 2 merges by hand.

I count 3 merges necessary to create the 8 tile, 1 merge necessary to create the 4 tile then I subtract 2 merges (1 for each of the two free 4-tiles). Therefore I count (3+1)-2=2 merges.

I don't understand how my calculation disagrees with "When two tiles combine together to form the next tile in the sequence" ? Stefan and I both count 2 merges by this definition.

 

[Stefan]

Please help me to see how. Stefan counts 2 merges by hand.

I count 3 merges necessary to create the 8 tile, 1 merge necessary to create the 4 tile then I subtract 2 merges (1 for each of the two free 4-tiles). Therefore I count (3+1)-2=2 merges.

I don't understand how my calculation disagrees with "When two tiles combine together to form the next tile in the sequence" ? Stefan and I both count 2 merges by this definition.

So you do count two merges there? Then do you agree now that Ricardo was correct? That you can't average more than one merge per turn?

 

[Methuselah96]

Please help me to see how. Stefan counts 2 merges by hand.

I count 3 merges necessary to create the 8 tile, 1 merge necessary to create the 4 tile then I subtract 2 merges (1 for each of the two free 4-tiles). Therefore I count (3+1)-2=2 merges.

I don't understand how my calculation disagrees with "When two tiles combine together to form the next tile in the sequence" ? Stefan and I both count 2 merges by this definition.

Sorry, I read the quote from Stefan's message and did not keep on reading from your original post. I'll read more carefully next time.

 

[TDM]

So close Am I the only one to have not yet completed it?

 

[Sa967St]

Third 2048 success: 7:16.62

Fourth success: 6:20.97

Seventh success: 5:33.66

ninth success: 4:47.91

 

[kcl]

Finally 2048 success! Didn't time it. Oh well.

 

[Jaycee]

Methuselah96: Nice edit!

16 tile: 9 turns, 7 merges
32 tile: 17 turns, 13 merges
64 tile: 39 turns, 34 merges (got a bit inefficient for a brief period)
128 tile: 59 turns, 56 merges (aaand now I'm back on track)
256 tile: 120 turns, 114 merges
512 tile: 243 turns, 236 merges
1024 tile: 490 turns, 480 merges
2048 tile: 971 turns, 958 merges

6th win, BTW. I'm positive that I'm much slower than Sarah (7 minutes?! O.o)

 

[Rocky0701]

So close Am I the only one to have not yet completed it?

I haven't either, i got to where i had two 512's and one 1024, but i couldn't combine them.

 

[Stefan]

You choose to count the number of merges in this example by counting them by hand. I choose to count the merges by looking at the face values of the tiles on the board. I choose my method so that I can extend it to boards with tiles with very large face values.

I did count it by hand in that tiny example. For larger examples I'd let the computer count. Or if that's not available, I'd count the number T of turns and the number E of tiles I end up with and then simply calculate the number of merges as M=2+T-E. I think that's far simpler than your method, both the final calculation as well as the counting (T is easier than F because you don't need to look at the new tile and decide whether to count it, plus you already have T in your conjecture anyway).

Note that the minimum number of merges to create a tile with value N is:
\( \frac{N}{2}-1 \)

Not true, for example for N=4 this would mean you need a merge. But you really don't. And you can build an 8 with just one merge, don't need three. And so on.

You're clearly using two different definitions of "merge", and that's no good.

 

[cmhardw]

So you do count two merges there? Then do you agree now that Ricardo was correct? That you can't average more than one merge per turn?

Either you're still not reading my posts because you consider them "too long" or I'm not explaining myself well enough. I already covered that question. See the two quotations below:

Now it makes more sense why Jaycee's ratio of merges/turns is over 1. In a sense the units didn't match. The # of turns (507) that Jaycee reported is the number of global turns for the whole game. The number of merges to create a 1024 tile (511 merges) is only the number of merges for the one 1024-tile. The ratio of (511 merges / 507 turns) being larger than 1 confused me for some time, until I realized that the turns counted for the whole board, and the 511 merges only counted for the one tile. Not only that, but without taking into account the free 4-tiles given to you the ratio will go over 1.

Now let's use the version of the formula that takes into account how many "free" 4s you received.

\( \frac{-F+\sum_k m_k}{T} \)

\( \frac{-2+(3+1)}{2} \leq 1 \)

And now this ratio really is less than or equal to 1 again and there is no problem.

------------------

I did count it by hand in that tiny example. For larger examples I'd let the computer count. Or if that's not available, I'd count the number T of turns and the number E of tiles I end up with and then simply calculate the number of merges as M=2+T-E. I think that's far simpler than your method, both the final calculation as well as the counting (T is easier than F because you don't need to look at the new tile and decide whether to count it, plus you already have T in your conjecture anyway).

I think that's really elegant. I did not come up with the most elegant way to figure out how the merges/turns ratio during the game must be less than 1. You clearly have superior math skills and my method is clearly not the most elegant way to perform this calculation. Based on what I have seen so far my method still works, although it seems I was not clear in my definition of "merges" which I will attempt to correct at the end of my post below.

Stefan, I cannot stress enough how infuriating your posts can be to read sometimes. I write my posts keeping in mind how you are going to rip them to shreds when you read them. I have been doing this for years, as you have consistently, for years, ripped my math posts to shreds for either being "too long" or not being rigorous enough. I notice now that I get frustrated whenever I make a math post and see that you have responded to it.

Your solution is more elegant than the one I came up with. You win. You are the man. Is this what you are looking for with your posts? You have succeed in correcting the worthless dribble that I post, good job sir.

Not true, for example for N=4 this would mean you need a merge. But you really don't. And you can build an 8 with just one merge, don't need three. And so on.

You're clearly using two different definitions of "merge", and that's no good.

Thank you for correcting the discrepancy in my terminology. Let me try to explain my thoughts.

Without having said it, I have been approaching the 2048 game as a variation on a "pure" form version of this game where after each turn the user is given a 2-tile, with no exceptions.

In this "pure" form version of the game, a 4-tile would always require 1 merge to be created. It would be created by the player merging two 2-tiles. In this "pure" form version of the game, a tile with the value N would always be created using \( \frac{N}{2}-1 \) merges by the user. It is possible for the user to perform multiple merges during one turn.

The "real" version of 2048 will give the user 4-tiles after a turn sometimes. I then decided to use the formula from the "pure" version of the game, namely that the N-tile can be created in \( \frac{N}{2}-1 \) merges and adjust it for the fact that sometimes a 4-tile has been given for free. This is less efficient than your method, but from what I have seen so far my formula will still calculate the number of merges initiated by the user just as accurately as your formula. I called it a conjecture because I don't have the math knowledge yet to prove my formula for every case. You have more math schooling and knowledge than I do, so if you can disprove my formula rigorously then clearly my formula was not correct. As far as I can tell you have pointed out the error in my explaining my formula so far, but no errors in how the formula calculates the number of merges made by the user.

I may have made even more errors in this very post, and if you point them out I will do my best to either try to correct them if they can be corrected, or admit that my formula is not true if you disprove it.

Stefan, I really respect you as a person and as a cuber. I like spending time with you in person at competitions. I like you enough to tell you that your forum personality can be very infuriating to talk to.

 

[Stefan]

I think I have more to say, but I'll re-read your posts more carefully first. For now let me just say I'm sorry. You're among the people I like and respect and care about most, and I'm really unhappy having frustrated and infuriated you. I'm aware I'm somewhat confrontational, but I didn't realize it could make you feel that way that much. Sorry.

 

[uyneb2000]

My first success!
What strategies do you guys use?
Here's a video of my ending.

 

[brian724080]

My first success!
What strategies do you guys use?
Here's a video of my ending.

Nice, but you could've won much more easily. You can fill up the three left-most columns with useless blocks, making sure that they don't merge with an up/down move, and then shift the rightmost 128 up by one block to win.

 

[Lucas Garron]

Here's a version I made up real quick that counts your turns and merges: http://fantasy.cubing.net/2048.htm

Feature request: Record all the moves (and the location/value of new tiles) and/or support playbacks!

(Preferably store all my history of solves in localStorage. Don't really care how sharing works.)

 

[Jaycee]

I fell into a trance while making the first 2048, and it just went smoothly from there.



Game over:

Spoiler

 

[Sa967St]

Here's a version I made up real quick that counts your turns and merges: http://fantasy.cubing.net/2048.htm

Awesome, thanks!


Here's a (somewhat) interesting observation: \( \#\ of\ turns\ =\ \#\ of\ merges\ +\ \#\ of\ active\ tiles\ -\ \#\ of\ active\ tiles\ on\ turn\ 0 \).

Assuming this is true, in order for \( \frac{\#\ of\ merges}{\#\ of\ turns} \) to equal 1, there must be exactly two tiles on the board, which (other than on turn 0) is possible on your first turn, if you start with two 2s that are aligned (and also on the following second turn if the next block is 4 and is aligned with the previous 4). In order for that ratio to be greater than one, there must be exactly one tile on the board, which is impossible. So, the ratio is always \( <=1 \).

 

[Stefan]

Here's a (somewhat) interesting observation: \( \#\ of\ turns\ =\ \#\ of\ merges\ +\ \#\ of\ active\ tiles\ -\ \#\ of\ active\ tiles\ on\ turn\ 0 \).

Assuming this is true

It is indeed true, I [post=963309]ended up[/post] with the same, though it's really just [post=963076]Ricardo's insight[/post] fleshed out a little.

 

[Sa967St]

It is indeed true, I [post=963309]ended up[/post] with the same, though it's really just [post=963076]Ricardo's insight[/post] fleshed out a little.

Ah, I should've read more of the thread. Can you think of a way to prove it without just observing arbitrarily many cases? Also, would it still be true if you start with three or four tiles instead of two? I assume so, but it's strictly from observation.


Another (more) interesting observation, which I can actually prove:

Let the nth tile have value t(n). (t(0)=2, t(1)=4, t(2)=8, etc.) Then if you receive only a 2 on every turn (no 4s), the your score is \( \sum_s nt(n) \), for all active tiles s with degree n and value t(n).

Proof:
Using the scoring system, each active tile with degree n, when first merged, accumulates 2p(n-1)+t(n) points, where p(n-1) are the points accumulated from the (n-1)th tile.
Since p(0)=0, we get the following when we receive only 2s:

p(1) = (2 x 0) + 4 = 4
p(2) = (2 x 4) + 8 = 16
p(3) = (2 x 16) + 16 = 48
p(4) = (2 x 48) + 32 = 128
p(5) = (2 x 128) + 64 = 320
p(6) = (2 x 320) + 128 = 768
p(7) = (2 x 768) + 256 = 1792
p(8) = (2 x 1792) + 512 =4096
p(9) = (2 x 4096) + 1024 = 9216
p(10) = (2 x 9216) + 2048 = 20480

Note the following:

p(0) = 0 = 0 x 2
p(1) = 4 = 1 x 4
p(2) = 16 = 2 x 8
p(3) = 48 = 3 x 16
p(4) = 128 = 4 x 32
p(5) = 320 = 5 x 64
p(6) = 768 = 6 x 128
p(7) = 1792 = 7 x 256
p(8) = 4096 = 8 x 512
p(9) = 9216 = 9 x 1024
p(10) = 20480 = 10 x 2048

This is exactly p(n)=nt(n) (since t(n)=2^(n+1)). [very lazy way of finding an explicit formula for a recursive equation, I know]

So each active tile of degree n and value t(n) accumulates nt(n) points, and the total score is the sum of all points of each active tile, which is precisely \( \sum_s nt(n) \), for all active tiles s with degree n and value t(n).

Q.E.D.
________________________________________________________________________________________________________________________________


Also, since it's unrealistic to only get 2s and no 4s, it follows that your score is actually \( \sum_s nt(n)-4f \), for all active tiles s with degree n and value t(n), where f is the total number of 4s given.


Question: Does anyone know the probability of a getting a 4 instead of a 2?

 

[Stefan]

Can you think of a way to prove it without just observing arbitrarily many cases? Also, would it still be true if you start with three or four tiles instead of two?

I consider Ricardo's first sentence the proof. Is it not clear enough?

Question: Does anyone know the probability of a getting a 4 instead of a 2?

Looks like 10%:

// Adds a tile in a random position
GameManager.prototype.addRandomTile = function () {
  if (this.grid.cellsAvailable()) {
    var value = Math.random() < 0.9 ? 2 : 4;
    var tile = new Tile(this.grid.randomAvailableCell(), value);

    this.grid.insertTile(tile);
  }
};

From http://gabrielecirulli.github.io/2048/js/game_manager.js

 

[vcuber13]

Question: Does anyone know the probability of a getting a 4 instead of a 2?

1/10, assuming javascript has an equal distribution, which I think it does.

// Adds a tile in a random position
GameManager.prototype.addRandomTile = function () {
  if (this.grid.cellsAvailable()) {
    var value = [B]Math.random() < 0.9[/B] ? 2 : 4;
    var tile = new Tile(this.grid.randomAvailableCell(), value);

    this.grid.insertTile(tile);
  }
};