Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Traversal as opposed to grid representation #19

Open
lucashutyler opened this issue Jul 14, 2023 · 1 comment
Open

[Discussion] Traversal as opposed to grid representation #19

lucashutyler opened this issue Jul 14, 2023 · 1 comment

Comments

@lucashutyler
Copy link

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)."

Size Direction Sets Notes
1 no movement allowed
2 n e, w, s are rotations
3 (n: n)
(n: e)
we can only start from previous terms
4 (n,n: n)
(n,n: e)
(n,e: n)
(n,e: s)
(n,e+n or n,n: s,e)??
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!
@moll-dev
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants