Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wave Function Collapse library in pure C

github.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Wave Function Collapse library in pure C

#81

Post by sledgehammers »

titzer wrote: post #80
flohofwoe wrote: post #73

Earlier quoted context omitted.

An STB-style header with the implementation disabled (which is the default) looks exactly the same to the compiler as a regular C header which only contains public API declarations (e.g. just struct declarations and function prototypes, and most importantly, no inline code). All code that would otherwise live in .c files is between an #ifdef/#endif block which is only activated in a single compilation unit in the who…

Sure, after brushing up on this "stb style", then I see what you mean. Still, it seems like an ugly kludge to cope with a breathtakingly antiquated way of doing things.

Why should it be any more complicated than that?

What ever happened to keeping it simple?

Re: Wave Function Collapse library in pure C

#82

Post by titzer »

sledgehammers wrote: post #81
titzer wrote: post #80

Earlier quoted context omitted.

Sure, after brushing up on this "stb style", then I see what you mean. Still, it seems like an ugly kludge to cope with a breathtakingly antiquated way of doing things.

Why should it be any more complicated than that? What ever happened to keeping it simple?

Things can be locally simple but have complex and chaotic implications. E.g. just by pushing the complexity up a level and dumping it on literally everyone else. I've learned over the years that complexity sometimes has a right place and a wrong place. (Most times complexity ends up everywhere, TBH.) I think resolving references between different parts of code in different compilation units is definitely within the purview of a compiler/build system, and should not be up to every programmer to flail at poorly with #ifdefs.

Re: Wave Function Collapse library in pure C

#83

Post by raattgift »

pixelpoet wrote: post #40
judofyr wrote: 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).

I think it is (in this usage) meant as the gain in human understanding of the photoelectric effect (Einstein 1905), specific heat, diamagnetism, and so forth once quantum mechanics began development. The leap from classical mechanical theories being fundamental to quantum mechanical theories being fundamental (with classical physics emerging from that), in other words, was a big shift even though subatomic particles themselves, and their bound states, are generally very small.

Random doesn't really enter into it. One can get that in a firmly non-quantized theory, as in one of Einstein's other 1905 papers, https://en.wikipedia.org/wiki/Brownian_motion#Einstein's_the... https://history.aip.org/exhibits/einstein/essay-brownian.htm https://physicsworld.com/a/einsteins-random-walk/

Re: Wave Function Collapse library in pure C

#84

Post by eru »

ImHereToVote wrote: post #48
pixelpoet wrote: post #40

Earlier quoted context omitted.

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

Yes, but the quantum leaps in physics are small.

Re: Wave Function Collapse library in pure C

#85

Post by flohofwoe »

titzer wrote: post #80
flohofwoe wrote: post #73

Earlier quoted context omitted.

An STB-style header with the implementation disabled (which is the default) looks exactly the same to the compiler as a regular C header which only contains public API declarations (e.g. just struct declarations and function prototypes, and most importantly, no inline code). All code that would otherwise live in .c files is between an #ifdef/#endif block which is only activated in a single compilation unit in the who…

Sure, after brushing up on this "stb style", then I see what you mean. Still, it seems like an ugly kludge to cope with a breathtakingly antiquated way of doing things.

> with a breathtakingly antiquated way of doing things.

I think it's mainly a fix/workaround for the breathtakingly antiquated build systems in the C/C++ world ;)

In the end, STB-style single-header vs. a single .h/.c pair is not all that different, both are equally straightforward to integrate into a project.

The actual problem are libraries made of dozens/hundreds/thousands of header and source files and coming with their own complex build system setup.

Re: Wave Function Collapse library in pure C

#86

Post by thomasahle »

I tried to use this to generate Numberlink puzzles. As the input I gave a solved image from https://github.com/thomasahle/numberlink . However I never even got to the "progress screen" / "cells collapsed" count. I guess the input image has to be very small for this to work well.

I also tried generating some large images (like 1000x1000 pixels output, but small 64x64 input), but it only collapses around 100 cells/second, so this still takes about 3 hours assuming no contradictions are encountered.

Works well for small inputs and outputs though!

Post reply on HN