You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a list of directions instead of a representation of the polycubes inside a n-dimensional array. Start with 2D for simplicity. For 2D we will just go "north (n), south (s), east (e), west (w)."
how to define the "T" tetromino splitting or backtracking?
Using a logic like this it feels like we could develop a set of rules for traversal. We might be able to determine that certain "turns" would simply be unallowed (overlap previous blocks, produce rotations, etc).
To elevate this to 3D, we would only have to add up and down.
Size
Direction Sets
Notes
1
no movement allowed
2
n
e, w, s, u, d are all "rotations"
3
(n: n) (n: e)
-
4
(n,n: n) (n,n: e) (n,e: n) (n,e: s) (n,e: u) (n,e+n or n,n: s,e) (n,e+u or n,e: w,u) (n,w: u or n,u: e)??
the last one is a mirror of (n,e: u) and not derived from the previous set
We'd have to go a few more terms to try to find more "rules" when adding on to previous sets.
While this could easily be hashed, ideally we would not have to hash anything and just have a set of rules that are followed until completion, giving us our number of shapes possible.
Immediate Concerns
Right away there is the question of how we "know" that there are rotations. Limiting movement to "only east or up," "only branch in opposite directions or at 90 degress" or something may work for the first few terms, but I'm scared of the strong law of small numbers and finding some extra rule at n=10 or n=100.
When thinking about n=5, (n,e,e,s) is already not derived from any n=4 path. We could do another split early and go (n+e,-reset-,n,e). Maybe slitting earlier would be prefable?
Also, we need to handle multiple splits and decide on a better representation of "subpaths" off of split branches. For example in n=7, we have a "big T" that could be (n,n,(w,w),(e,e)) or something weird like that.
Thanks!
Thank you for the ability to think about this. These questions are the kind of questions that got me to be a programmer. Maybe I'll get carried away and take a stab at writing some code to generate some numbers!
The text was updated successfully, but these errors were encountered:
This was something I was playing with, I think it hits a wall while trying to compare all rotations. Generating polycubes is relatively easy, just add a new cube adjacent to an existing one, but the complexity comes from comparing it against previously seen ones.
Explanation
Consider a list of directions instead of a representation of the polycubes inside a n-dimensional array. Start with 2D for simplicity. For 2D we will just go "north (n), south (s), east (e), west (w)."
(n: e)
(n,n: e)
(n,e: n)
(n,e: s)
(n,e+n or n,n: s,e)??
Using a logic like this it feels like we could develop a set of rules for traversal. We might be able to determine that certain "turns" would simply be unallowed (overlap previous blocks, produce rotations, etc).
To elevate this to 3D, we would only have to add up and down.
(n: e)
(n,n: e)
(n,e: n)
(n,e: s)
(n,e: u)
(n,e+n or n,n: s,e)
(n,e+u or n,e: w,u)
(n,w: u or n,u: e)??
We'd have to go a few more terms to try to find more "rules" when adding on to previous sets.
While this could easily be hashed, ideally we would not have to hash anything and just have a set of rules that are followed until completion, giving us our number of shapes possible.
Immediate Concerns
Thanks!
The text was updated successfully, but these errors were encountered: