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.
Since it's a *=, I'd expect the operation to occur in double, quantize accordingly, and handle overflow as double-to-int would, rather than int multiplication would.
For 10.0 specifically, double is more than large enough to, as far as I know, result in the same output. For arbitrary double literals, I wouldn't expect this to be the case.
Note: overflow cast from double to int is undefined, last I looked, so one could argue that the numerical regions for which quantization would occur are outside of the practical range of this chunk of code.
It is still valid after constant lifting or if the range of the long int in question vs can be proven to be representable in 53 bits or less. (E.g. using the polyhedral loop optimizer gcc has.)
I'd be more curious what Clang did for values that would result in different behaviors for some ranges of a. I understand that there are limits, and that there is range checking in literals for escalation to, for instance, 64-bit values, but it seems like an optimization that is:
A) fraught with edge-case peril
and
B) easily accounted for by the developer (e.g. write "a *= 10;")...
> I'd be more curious what Clang did for values that would result in different behaviors for some ranges of a.
I don't think I understand what you mean. Can you give an example?
As for "the developer should write what they mean", one standard answer from compiler developers is along the lines of "but this code might not be hand-written, it might come from a primitive code generator". You can decide whether that convinces you or not ;-)
Yeah. I'm partially unconvinced. That is to say that, if the compiler Dev wants to take on the completeness responsibility, cool. If not, I'm okay with that, too. Adding the optimization and screwing up the edge cases is the only way to end up on my bad side.
An example number might be 8388608.0 (or 2^23). Hell could have broken out more than four million integer values before that, but it's as nice a test as any (except maybe the exact edge).
There could also be interesting cases of compound arithmetic literal statements. And then, of course, there are other side-effect considerations (e.g. the x87 opcode register).
I'll stick to getting my literal types right in the first place, but, as stated above, it doesn't feel like a real miss to me. Either a dev or a code generator wrote ".0". I'm inclined to respect that to some degree.
Probably because I'm old.
I'll compile this in gcc and clang and see what shakes out. My bet is that clang does the right thing once the value is out of safe range.
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)
I don’t think that audio-only version comes from Youtube. I think youtube-dl downloads the whole video, then uses ffmpeg to extract and possibly re-encode its audio channel.
No, YouTube does have audio-only streams. You can use "youtube-dl -F [url]" to view the available formats and their codes.
They're meant to be paired with the video-only streams used for some resolutions (most notably 1080p). Even browser extensions such as YouTube Center can download the streams, and they certainly don't use ffmpeg.
(In fact, I do use ffmpeg to combine audio-only and video-only streams via youtube-dl, e.g. "youtube-dl -f 137+141 [url]" which takes 1080p video and 256k aac audio.)
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.
> 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
That's not a mistake. GitHub, like 99.99% of the Internet, doesn't allow cross-origin XHR for their pages (that's a security vulnerability). So they have to use <script> which doesn't follow the Same Origin Policy.
Though that's a bit silly, given they could've also used <img> which wouldn't be vulnerable to XSS.
So the text I quoted should say something like [with appropriate expansion and fact checking]:
"Requests from other countries to Baidu's CDN in China are intercepted by the government firewall - the returned web pages load content from GitHub or NYT that is hidden from the user. Each affected Baidu user outside China's browser sends content requests to those content suppliers whenever they follow a link in Baidu's search results. With Baidu's immense popularity this is causing a DDoS of the content suppliers servers preventing genuine user's browser requests from being handled."
What's the actual injected code? Presumably one can get it by requesting a link on a Baidu SERP?
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.
A real time calculated displacement map would be more appropriate. These simulations typically use real wave-front physics (Navier-Stokes), even if simplified.
