-
Notifications
You must be signed in to change notification settings - Fork 3
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
Make hexagonal_lattice_graph
more consistent between periodic and non-periodic
#57
Comments
The current design is based off of Networkx in Python: https://networkx.org/documentation/stable/reference/generated/networkx.generators.lattice.hexagonal_lattice_graph.html So you get the same output there: I agree it would be better to just have a non-periodic version and then a periodic version that calls that and adds edges and still has the same number of vertices. Unlike the square lattice, however, I think it is a bit more tricky to do that because there is a slight complexity of which vertices should actually wrap around to which ones in the periodic case in order to preserve the hexagonal structure. This is why Hence, as far as I understand, you can't just take the open boundary version and add edges (it would break the properties of the hexagonal lattice). You would need to create a new open boundary version which looks slightly weird because the right side of the right-most column would be broken and have some `dangling' vertices. |
You're probably right. I think I was partially confused by #59, and not being sure how to interpret |
Yeah |
Makes sense, thanks for the clarification, I think besides #59 the behavior makes sense. |
Changing the setting of
periodic
inhexagonal_lattice_graph
changes the lattice size:I think instead it should output graphs with the same number of vertices and structure, just with extra periodic edges if
periodic=true
. It is implemented that way right now because the periodic graphs are constructed by first constructing the corresponding non-periodic version of the lattice and then merging vertices, it could still be implemented that way with some code restructuring, for example having an inner non-periodic version which the periodic version calls. The current design makes it difficult to reason about what size lattice will get output. (@JoeyT1994)The text was updated successfully, but these errors were encountered: