Simple Combo/Permute calculation

Click For Summary

Discussion Overview

The discussion revolves around calculating the number of possible product configurations in a game called Shapez, where players create shapes using various resources. Participants explore the combinatorial aspects of symmetrical and asymmetrical products, considering factors such as shape types, colors, layers, and rotational symmetry.

Discussion Character

  • Exploratory
  • Mathematical reasoning
  • Debate/contested

Main Points Raised

  • One participant proposes that the number of symmetrical products is calculated as 4 (shapes) x 7 (colors) x 4 (layers), leading to 112 configurations.
  • Another participant suggests that for asymmetrical products, the calculation should be 112^4, resulting in approximately 157 million configurations.
  • Some participants question whether adjacent layers must be different colors, with varying responses indicating uncertainty about this rule.
  • There is discussion about whether certain configurations, such as stacking the same shape on top of itself, are valid, with some asserting that they are not ruled out.
  • One participant calculates total symmetrical configurations as 28 + 28^2 + 28^3 + 28^4 = 637,420, but others challenge the assumptions behind this calculation.
  • Concerns are raised about the complexity of removing rotationally symmetric configurations from the total count, with one participant noting that this could significantly complicate the combinatorial problem.
  • There is a debate about whether layer dependencies exist, with some asserting that layers are independent while others suggest that the configuration of one layer may affect the options for another.

Areas of Agreement / Disagreement

Participants express multiple competing views on the calculations and assumptions involved, particularly regarding the treatment of layers, rotational symmetry, and the validity of certain configurations. The discussion remains unresolved with no consensus reached.

Contextual Notes

Participants highlight potential issues with layer dependencies and the removal of rotational symmetries, indicating that these factors complicate the calculations. There is also uncertainty about the rules governing color combinations and the stacking of shapes.

  • #31
DaveC426913 said:
You are technically correct, but your choice of rendering is going to lead to misunderstandings, tears and heartbreak. Remember, we're not the only ones reading this thread. :wink:
We've already changed it multiple times! The objective is to get to the base level abstraction of how to count configurations for this game.

EDIT:
Even now I'm still not sure we are in agreement based on the edits made in #26! It seems like this:

1683818481111-png.png

is just:

1683818516023-png.png


( Are there 3 white filled quadrants in this figure not shown?)

Disagrees with my assertion that:

1683821476729.png
 
Last edited:
Mathematics news on Phys.org
  • #32
erobz said:
We've already changed it multiple times!
I know; I was originally using a shorthand, thinking I only represented what was needed, but it turns out that was wrong and that ambiguity has caused confusion.

Abstraction is one thing, but misrepresentation is not good for communication.

This is the minimal graphic required to represent valid permutations. It needs grey, it needs white and it needs null.
erobz said:
Even now I'm still not sure we are in agreement based on the edits made in #26!
Here is your product:
1683821952929.png


It is legal, and difficult to build.
But how it is built does not factor into the permutations.I'm also seeing a text version that looks like this:
RgRg|--Rg
----|Rb--

Which means:

Layer 1: squaRe-green, squaRe-green | empty, squaRe-green
Layer 2: empty, empty | squaRe-blue, empty
Personally, while that's good codification, I find it less than visually intuitive.
 
Last edited:
  • #33
DaveC426913 said:
I know; I was originally using a shorthand, thinking I only represented what was needed, but it turns out that was wrong and that ambiguity has caused confusion.

Abstraction is one thing, but misrepresentation is not good for communication.

This is the minimal graphic required to represent valid permutations. It needs grey, it needs white and it needs null.

Here is your product:
View attachment 326394

It is legal, and difficult to build.
But how it is built does not factor into the permutations.
Ok, so you are saying the little blue square placed on an empty layer (grey placeholder) will not resize, and move to the base layer like shown in #23?
 
  • #34
erobz said:
Ok, so you are saying the little blue square placed on an empty layer (grey placeholder) will not resize, and move to the base layer like shown in #23?
Right. Mostly.
It can be done, but it's a process that involves cutting and re-combining and disposing of objects in a complex way. I could go into it if you want; it's all laid out in the game guide, but that's behind a passwall, so I'd have to copy and paste the section of the article.

And I just realized that vastly complicates the calculations of the total permutations. Not I'm no longer sure that there are simply static rules, so much as there are procedures (algorithms).
 
  • #35
DaveC426913 said:
Right. Mostly.
It can be done, but it's a process that involves cutting and re-combining and disposing of objects in a complex way. I could go into it if you want; it's all laid out in the game guide, but that's behind a passwall, so I'd have to copy and paste the section of the article.
Not necessary. I thought you were saying it was not a valid config in 23. Forget I ever said anything.
 
  • #36
I think I'd be satisfied with just knowing the possible symmetrical shapes, which I think is simply
(4x8)+(4x8)2+(4x8)3+(4x8)4, as you eluded to way back at the start.
 
  • Like
Likes   Reactions: erobz
  • #37
DaveC426913 said:
And I just realized that vastly complicates the calculations of the total permutations. Not I'm no longer sure that there are simply static rules, so much as there are procedures (algorithms).
We are operating under the assumption that you can in theory get to every configuration, we aren't talking about the likelihood of reaching a particular configuration.
 
  • #38
erobz said:
We are operating under the assumption that you can in theory get to every configuration, we aren't talking about the likelihood of reaching a particular configuration.
We don't even know what "every" configuration is. That trick, where a layer 2 shape is melted into layer 1, throws the combinations count into chaos because it means the "rules" for validity are ambiguous.

eg.: how many combinations are added if you melt a layer 4 all the way down to level 1? What about melting a level 4 down to level 3 and a level 2 down to level 1? The possibilities are virtually limitless.

Regardless of how it might be done or even if it can be done, simply counting them becomes an intractable problem.
 
  • #39
DaveC426913 said:
We don't even know what "every" configuration is. That trick, where a layer 2 shape is melted into layer 1, throws the combinations count into chaos because it means the "rules" for validity are ambiguous.

eg.: how many combinations are added if you melt a layer 4 all the way down to level 1? What about melting a level 4 down to level 3 and a level 2 down to level 1? The possibilities are virtually limitless.

Counting "every" configuration suddenly becomes an intractable problem.
Well, if some higher level converts like that, the new configuration was already counted. Probably safe to say what @pbuk computed ##2.0 \times 10^{24}~\rm{shapes} ## is an upper bound and leave it at that.
 
  • Like
Likes   Reactions: DaveC426913
  • #40
I feel like I've led you guys on a wild goose chase, only to find we're back where we started. :woot:
 
  • #41
DaveC426913 said:
I feel like I've led you guys on a wild goose chase, only to find we're back where we started. :woot:
Overall forward progress was made!
 
  • #42
Yes, ultimately the answer to the question: Would it be tactically useful to create factories that produce each type of major shape in anticipation of future levels needing them? is: probably not.
 
  • #43
DaveC426913 said:
Yes, ultimately the answer to the question: Would it be tactically useful to create factories that produce each type of major shape in anticipation of future levels needing them? is: probably not.
:oldsurprised: I didn't even realize there was a point to this beyond trying to figure out how may shapes there are!
 
  • #44
DaveC426913 said:
We don't even know what "every" configuration is. That trick, where a layer 2 shape is melted into layer 1, throws the combinations count into chaos because it means the "rules" for validity are ambiguous.

eg.: how many combinations are added if you melt a layer 4 all the way down to level 1? What about melting a level 4 down to level 3 and a level 2 down to level 1? The possibilities are virtually limitless.

Regardless of how it might be done or even if it can be done, simply counting them becomes an intractable problem.
I don't know what you mean by "melting down". There is no trick, now I've played the game the rules are simple: every layer must have at least one quadrant occupied.

That's it.

I think you are missing the simple trick that enables you to make the "hanging" quadrant in the 'logo' shape: it is made in two halves.

There is an open access wiki on Fandom, I haven't looked at it much (it spoils the fun) but it's easy enough to figure out the game mechanics if you have played things like SpaceChem, Factorio etc.
 
  • #45
pbuk said:
I don't know what you mean by "melting down". There is no trick, now I've played the game the rules are simple: every layer must have at least one quadrant occupied.

That's it.

To make this shape:
1683861714500.png


I assume you concur with this:
1683861319393.png
When layer 2 is stacked on top of layer 1, they "melt" together to become one layer. But, importantly, the blue square will not shrink. i.e. you cannot build the requested shape this way.

There is a trick to it, but it requires multiple steps. I wouldn't call it "simple" if I had to discover it on my own. To you, being more experienced with similar games, I guess it is not new.
 
Last edited:
  • #46
DaveC426913 said:
I assume you concur with this:
View attachment 326413

Yes of course, but shape(1).png plus shape(2).png equals shape(4).png.

You can easily make the first shape by cutting a shape(3).png in half.

DaveC426913 said:
To you, being more experienced with similar games, I guess it is not new.
Perhaps, although I find that this type of game exercises the same parts of my brain as I use when writing code - particularly in a low level languge with RISC machine code at the far end of that spectrum! For a game with a more explicit link to coding, try https://en.wikipedia.org/wiki/TIS-100.
 

Similar threads

  • · Replies 13 ·
Replies
13
Views
4K
Replies
15
Views
41K
  • · Replies 5 ·
Replies
5
Views
3K
  • · Replies 1 ·
Replies
1
Views
4K
  • · Replies 1 ·
Replies
1
Views
3K