Live data from Hacker News

Wave Function Collapse library in pure C

github.com

41–50 of 87 posts

Re: Wave Function Collapse library in pure C

#41

I feel like the algorithm is maybe poorly named. At first I thought this was a tool to help with computational quantum physics.

This gets brought up every time its mentioned. And I think its interesting. It's only tangentially related to actual physics. But parallelizing the WFC for large inputs might be exactly the kind of problem QC assists.

Re: Wave Function Collapse library in pure C

#42
post #35

Earlier quoted context omitted.

Learning something doesn't stop it being terrible. One time I ran `cmake`, and forgot to run `sudo -k` beforehand. It reconfigured my system.

That has more to do with sudo than cmake.

This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that.

I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.

Re: Wave Function Collapse library in pure C

#44
post #3
post #2

I wonder why the implementation is all in a header.

This is a typical idiom frequently seen in modern C and C++ codes. As https://github.com/krychu/wfc#how-to-use-the-library says, you need to define a macro in a C file in order to "expand" the actual code there. Having the code in the header gives a bit more flexibility considering the file layout. IMHO this is an awkward consequence of the missing de-facto-standard in C/C++ build systems.

All code in the header leads to a lot of duplicated work for the compiler, which means slow build times. You should avoid this unless it is absolutely necessary for performance to inline methods.

Re: Wave Function Collapse library in pure C

#45
post #35

Earlier quoted context omitted.

That has more to do with sudo than cmake.

This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that. I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.

Any build tool can do whatever they feel like.

Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.

Re: Wave Function Collapse library in pure C

#46
post #45

Earlier quoted context omitted.

This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that. I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.

Any build tool can do whatever they feel like. Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.

Sure, but should it? Do you really want nasal demons from your build tool?

Re: Wave Function Collapse library in pure C

#47
post #33

Earlier quoted context omitted.

As someone who has actually studied physics (including quantum mechanics) I find this analogy extremely poor. Keeping multiple potential candidates which you gradually reduce into a single solution is a very common approach for solving a variety of problems (e.g. sudoku solver). This is not at all what makes the wave function interesting or useful in quantum mechanics. And the whole concept that you iteratively colla…

> Oh well, I guess people like the fancy name. The way "quantum leap" is used by laypeople springs to mind too; literally the opposite of what they mean (not only tiny but random).

is it though? I've heard the argument, but to me it still makes sense as it is used colloquially. It is a discrete jump forward, thus if you are not talking about electrons and just the latin definition can be an arbitrary sized quanta if defined to an an appropriate set. a quantum leap between scientific epochs is quite large for example

also just reread your comment. I don't agree with the definition "small and random", it is smallest unit of measurement an arbitrary system magnitude can change

Re: Wave Function Collapse library in pure C

#48
post #33

Earlier quoted context omitted.

As someone who has actually studied physics (including quantum mechanics) I find this analogy extremely poor. Keeping multiple potential candidates which you gradually reduce into a single solution is a very common approach for solving a variety of problems (e.g. sudoku solver). This is not at all what makes the wave function interesting or useful in quantum mechanics. And the whole concept that you iteratively colla…

> Oh well, I guess people like the fancy name. The way "quantum leap" is used by laypeople springs to mind too; literally the opposite of what they mean (not only tiny but random).

Quantum does not mean "small and discrete", it only means "discrete", as in "quantisation" - fitting values into a discrete defined set. For instance in mathematics the operation of "rounding" quantises fractions into the set of integers.

Re: Wave Function Collapse library in pure C

#49

Reminds me of the 5-star WFC code on github: https://github.com/merrell42/model-synthesis/blob/master/src... int***** support; see https://paulmerrell.org/wp-content/uploads/2021/07/compariso... Pierre Terdiman from nvidia is doing some experiments using it, for Omniverse level generation: https://twitter.com/PierreTerdiman/status/147663502794968678...

eli5 int*** support;

Re: Wave Function Collapse library in pure C

#50
post #44
post #3

Earlier quoted context omitted.

This is a typical idiom frequently seen in modern C and C++ codes. As https://github.com/krychu/wfc#how-to-use-the-library says, you need to define a macro in a C file in order to "expand" the actual code there. Having the code in the header gives a bit more flexibility considering the file layout. IMHO this is an awkward consequence of the missing de-facto-standard in C/C++ build systems.

All code in the header leads to a lot of duplicated work for the compiler, which means slow build times. You should avoid this unless it is absolutely necessary for performance to inline methods.

That work will be done by the preprocessor and should be fairly quick given it doesn't compile the duplicated code and only removes it.
Post reply on HN