Talk:Wave function collapse

Revision as of 14:28, 9 July 2022 by Rdm (talk | contribs)

Vote for deletion

We have been getting a bunch of new tasks lately with absolutely no verbiage or explanation of algorithm on the "task" page other than a link to "See the algorithm over there". If you can't be bothered to put summary a explanation of the algorithm, and better yet, an reference implementation, enough for a knowledgeable person to figure out how to do it, it comes across as a low effort attempt to drive traffic to somebodies monetized video / page. Not what RosettaCode is about. As it stands, I vote for deletion on this task. I have similar low opinions of Boyer-Moore string search, Knuth-Morris-Pratt string search and [[Execute_Computer/Zero]‎], but those are issues for other discussion pages. --Thundergnat (talk) 21:51, 8 July 2022 (UTC)

Seconded. Also added a clarify task tag to the main page. --Pete Lomax (talk) 02:44, 9 July 2022 (UTC)
Thirded? I've added a ref to boristhebrave.com, couldn't not in the current climate. We need to define the input file set. Each tile could be represented by four numbers N S E W. The constraint is N must match S vertically and E W horizontally. The concept of least entropy is essentially Warndorf and I've explored extending that beyond Knights tour elsewhere on RC.--Nigel Galloway (talk) 09:17, 9 July 2022 (UTC)

I've made this task before this video, but based on other videos. https://github.com/darkfrei/love2d-lua-tests/blob/main/wave-function-collapse/main.lua Sorry that I cannot good explain this task, but just added the link to good description. --Darkfrei (talk) 22:09, 8 July 2022 (UTC)

Could you derive from the Github code a completed working Lua example with input and output as you ask in the task, and post that as an solution? As it stands, the description seems disjointed. It is very short, yet includes details about things such as tile size and output characters that are difficult to understand without a documented example and more explanation in the task text. --Wherrera (talk) 00:59, 9 July 2022 (UTC)

First off... I agree with some of the general sentiments here. That said, I also think we should encourage new task authors to review the Rosetta_Code:Add_a_Task page -- especially the basic information section.

Meanwhile, though https://github.com/mxgmn/WaveFunctionCollapse looks like an implementation with clarifying examples, but that alone would not be enough to determine the correctness of an implementation here. (What's a "sufficiently large number of outputs"?).
That said, for a task like this, it might make sense to include the extensive contents of that README.md (discarding the image references, since they won't work here, maybe doing a little rephrasing in the language discussing them and maybe throwing in some ascii art for a critical example) from the top of the file down to (but not including) the How to build line, and then throw in a reference to that github implementation (especially since it links to other implementations).
That said, this task might be a bit big for rosettacode. That's somewhat characteristic of media-oriented coding. So I could live with skipping it... --Rdm (talk) 07:20, 9 July 2022 (UTC)
Also, ... after thinking about this a bit, it's not clear to me whether "edge of the image" (no adjacent pixels on one side or (for corners) two sides) should be treated as a "tile" (probably not: the other possibility, suggested by "tiling" is that each edge of a tile is connected to the opposite side of the image, meaning that we can select regions of pixels which would appear when repeating the image as a tile). But, ... I think that that kind of detail is an example of information which should go into the task description (if there was a task description). And... this gets back to the lack of any specific task examples presented here. --Rdm (talk) 07:40, 9 July 2022 (UTC)
There's probably also a constraint that the replication tiles (e.g. 3x3 sized tiles) are "aligned" on a grid which matches that tile size. And, given the "tiling" concept, ... conceptually if we were generating an 11x11 image with 3x3 tiles we'd do something like construt a 12x12 image and then crop it to 11x11. --Rdm (talk) 08:14, 9 July 2022 (UTC)
After playing with some implementations, I'm wondering if maybe there's a bit of smoke and mirrors in the implementation at https://github.com/mxgmn/WaveFunctionCollapse#. (I'm getting contradictions -- empty results -- so far for every attempt I've made, running my version of wave function collapse. This suggests that I am imposing a constraint which was not present in the github implementation. I have yet to determine what it is about my interpretation of the algorithm description which differs from that github implementation.)
For example, with a starting bitmap of:
1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 0 0 0 0 0 1
1 1 1 1 1 0 1 1 1 0 1
1 1 1 1 1 0 1 1 1 0 1
1 1 1 1 1 1 1 1 1 0 1
1 0 0 0 0 0 0 0 0 0 1
1 0 1 1 1 1 1 1 1 1 1
1 0 1 1 1 0 1 1 1 1 1
1 0 1 1 1 0 1 1 1 1 1
1 0 0 0 0 0 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1
and generating a 6 by 6 bitmap using 3x3 pattern tiles, I want to generate a 2 by 2 collection of pattern tiles. I randomly pick the first tile, and it's a 3 by 3 collection of 1s. But (unless I've goofed horribly) there's no 3x3 pattern tile which can have that pattern both above it and below it. --Rdm (talk) 10:27, 9 July 2022 (UTC)
And, if I relax the tile condition at the borders, that works for small examples like this, but larger examples still tend to run into contradictions. So maybe to make this work we need a mechanism to ignore contradictions? (Or perhaps my implementation is flawed? .. what would be a test case for correctness here?) --Rdm (talk) 14:10, 9 July 2022 (UTC)
Return to "Wave function collapse" page.