11–20 of 87 posts
I feel like the algorithm is maybe poorly named. At first I thought this was a tool to help with computational quantum physics.
I feel like the algorithm is maybe poorly named. At first I thought this was a tool to help with computational quantum physics.
Very naive question but is it even possible to do quantum experiments with code on a regular computer? Anyone knows if it's been tried?
https://marl0ny.github.io/QM-Simulator-2D/index.html
From the above link you can look single slit, double slit, triple slit, step, spike, or load an arbitrary image as a potential and do experiments in 2d box.
>This WebGL program simulates the quantum mechanics of a single particle confined in a 2D box, where inside this box the user can create new potential barriers and scatter Gaussian wavepackets off them. The full instructions are found here.
https://github.com/marl0ny/QM-Simulator-2D
btw. Wave function collapse in quantum physics is completely speculative phenomenon. There is only apparent wave function collapse.
Earlier quoted context omitted.
How is it more flexible exactly? I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentation, and this just obscures it. Depending on your compiler it can make debugging a huge pain as well.
It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.
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.
Earlier quoted context omitted.
How is it more flexible exactly? I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentation, and this just obscures it. Depending on your compiler it can make debugging a huge pain as well.
It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.
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.
You don't need an elaborate build system to add a single .c file to your project
It's just easier to have a single .h you include.
World.import(World.export(props))
Run that in an infinite loop.
Anyways this post ignited some deep contemplation
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.
How is it more flexible exactly? I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentation, and this just obscures it. Depending on your compiler it can make debugging a huge pain as well.
This still works nicely: the important stuff (documentation and public interface) is at the top, followed by the 'unimportant' implementation at the botton of the file.
STB-style headers are a bit different from typical C++ 'single header libraries' in that they put the declaration and implementation into separate sections in the header file (with the implementation inside an #ifdef/#endif pair), while C++ headers are usually a wild mix of class declarations intermixed with implementation code in template and inline functions (which is indeed harder to read).
I don't quite understand how debugging is affected? E.g. there are (usually) no inline functions in STB-style headers.
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.
Earlier quoted context omitted.
It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.
That would be easier if the most popular build systems weren’t terrible