This optimisation is actually fully correct if int is 32-bits wide. This is because doubles have a 52-bit mantissa, which means that they can exactly represent all integers up to 2^53 in magnitude. However you are right that the optimisation would not be valid, had int been 64-bits in width.
No, you're talking about a different problem: that of counting the total number of n-queens solutions. The original article is talking about the problem of deciding, given a partial placement of queens, whether it can be completed by adding further queens to form an n-queen solution.
This is only true assuming that P != NP, which is still an unsolved question.
Furthermore, NP-completeness only applies to decision problems. In this case the paper explores the problem of deciding whether or not there exists a path which will complete the track.
The upshot is, if there exists a polynomial-time algorithm to decide this question, then we can use this algorithm to solve all other NP decision problems in polynomial time.
Also, a fantastic visual guide is the documentary film "Moleman 2" (2011). It's freely available to watch on YouTube; highly recommended: https://www.youtube.com/watch?v=iRkZcTg1JWU
Consider two independent fair die rolls, with A and C being the outcomes. Let B be the sum of the outcomes. The higher A is, the higher B is likely to be, so A and B are positively correlated. So are B and C. However there is no correlation between A and C as they are independent.
Video codecs are good at compressing stills, so there's very little overhead in playing such a video when only the audio is desired.
That being said, YouTube does also encode audio-only versions of all their videos; they're not available from the web player though. You can use external software such as youtube-dl[1] to take advantage of it.
[1]: https://github.com/rg3/youtube-dl/ (using an invocation such as "youtube-dl -g -f bestaudio [url]" to retrieve the URL of an audio-only encode)
This was worded misleadingly. This is indeed a DDoS: code has been injected to load the Github pages in the background using XHR without the user's knowledge. The host page itself is not redirected (or visibly affected in any way[1]).
Furthermore, only people outside of China are affected by this -- Chinese citizens don't have this code injected.
[1]: Actually there is a mistake in the injected code that causes the result of the XHR request to be interpreted as JavaScript, and then executed. Hence GitHub has tried to mitigate the attack by replying 'alert("WARNING: malicious javascript detected on this domain")' to notify the user that this is happening.
Unfortunately the effects that you describe are nontrivial. The method of water simulation that is used here doesn't lend itself to simulating the effects of things like water tension or breaking waves. This is because the water surface is represented as a 2D height-map, representing the displacement from equilibrium (i.e. the z coordinate as a function of x and y). It's clear that it is not possible to represent water clinging to the sphere or dripping off it.
A particle-based system could simulate the effects you describe (by keeping track of the positions of some large number of water "molecules" and exchanging forces between each pair of particles), however the simulation would be far too costly to run in real-time on typical hardware today. It also has its downsides. With a height-map based representation it is trivial to calculate the normal to the surface of the water, which is necessary for the lighting effects, but with a particle system you would need to reconstruct the surface of the water in an additional step each frame, using something like the marching cubes algorithm.
Óscar Toledo G. has notably written various tiny, strong and highly obfuscated chess engines in C (winning the IOCCC twice) and JavaScript (2nd place in the first JS1k). He's even written a 170 page book to serve as a reference to the 1326-byte "Nanochess" program, his strongest small chess engine.
The trick is to perform damping around the edges in a hidden border around the heightmap.
Say you wanted to simulate a 500x500 heightmap. You would actually calculate the results for a 700x700 heightmap, (which contains a hidden border of width 100 around each edge). The hidden edges are slowly damped away by multiplying by a factor interpolated between 1 (on the inner edge of the visible part of the heightmap) 0 (on the very outside of the heightmap).
This works remarkably well; you can see this approach in action in http://www.falstad.com/ripple/ for instance. Source code is included on the page.
Řrřola (a famous demoscene coder [1]) found a far better constant than the original (a 2.7-fold accuracy improvement) by using an optimisation algorithm over all three constants present in the original inverse square hack.
His algorithm and the result (along with a plot of relative error) can be found on his blog [2].
Shameless plug: a while back I wrote an assembler-and-VM for a similarly hypothetical assembly language that I was studying in class. Just for kicks, I wondered if I could fit the entire thing into 1KB of JavaScript, whilst including features as step by step execution, a "debugging GUI" (as much as you could expect from 1KB!) featuring the stack, register contents and program counter, plus the assembler on top which performs full syntax/opcode argument checking.