HN user

chengsun

218 karma
  https://<username>.uk
  _@<username>.uk
Posts2
Comments45
View on HN

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.

This is not true in general.

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.

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

[1]: See, for example, this 256-byte raycaster https://www.youtube.com/watch?v=R35UuntQQF8

[2] http://rrrola.wz.cz/inv_sqrt.html

JSVM 13 years ago

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.

The result (which I'm pretty pleased with) is here: http://chengsun.github.io/ocremutiny.html

Fourier Toy 13 years ago

You can change the phase by holding ctrl-shift and dragging the circle. If you want a negative value just use the absolute magnitude with the component in antiphase.

Fourier Toy 13 years ago

The nth circle from the right is n times the speed of the first circle.

This seem legit... 13 years ago

If you repeatedly test another password, the prompt changes. Quite hilarious.

Also, the terms and conditions are fake too.

"If you read all the legalese up to this point (or just got there by random scrolling), you probably have noticed that this document is complete nonsense. [...] First, chapter 10 of Mary Shelley's /Frankenstein/. Second, a copy of some treaty."