fdej

> Locality: traditional runtime computations focus on Big O, the number of operations computed. However, for modern computing, moving data around in memory can be very time-consuming

I need to nitpick here... Big O notation is a way to describe growth rates of functions. You can count data movements (or anything else) with Big O.

Why? Humans first migrated out of Africa at least 100,000 years ago, which would give plenty of time to reach Australia by 65,000 years ago. The technology to build boats or rafts could easily have been forgotten over thousands of years if seafaring was not crucial to surviving on the new continent.

Same here. I will probably keep using Python 2 for as long as it works... simply because I don't have to type those parentheses.

Well, we could in principle build a computer capable of this level of understanding, and then use a brain-computer interface to augment our own understanding with the computer's...

Yes, and indeed, this is why life as we know it only works in a narrow temperature range: high enough for Brownian motion to drive reactions, low enough not to unravel the results too quickly.

Look at this analysis of the Falcon 9 flight profile, in particular the graph at the bottom right: https://www.reddit.com/r/spacex/comments/6303ko/falcon_9_ful...

The majority of the horizontal delta-V is produced in the second stage. The job of the first stage is to a large extent just to lift the second stage out of the densest part of the atmosphere, to minimize drag for the second stage. A plane can do the same thing, and possibly more cheaply in certain scenarios (well, that has to be Allen's plan anyway).

The power output of high level radioactive waste is of the order some watt per kg, comparable to animal metabolism. This is so little that the energy that could be extracted would be worth far less than the running costs for maintenance and security. However, there is the possibility of using breeder reactors to recycle fuel.

That improvement took about decade for computer chess, through a combination of algorithm and hardware improvements. A decade might be a reasonable ballpark estimate for Go as well (but even less than that is realistic). On the hardware side, I would not be surprised if analog circuits make a comeback.

No. Typical implementations use polynomial evaluation and range reduction. The advantage of CORDIC is that it only uses shifts and additions, and no multiplications. The disadvantage of CORDIC is that it converges very slowly. On modern hardware where multiplication is blazingly fast, CORDIC no longer makes sense.

If a computer crashes, you can identify the software or hardware flaw that caused the crash and fix it once and for all.

Improving human driving skills collectively is much more difficult. Even if one driver learns from their own mistake, other drivers and the next generation of drivers will still be just as prone as before to make that mistake. Better education can only do so much anyway, since people often don't think rationally and don't necessarily make safety the number one priority (e.g. drunk driving, trying to get to the destination as quickly as possible, or reckless driving for entertainment purposes).

Talk about method acting. The creators truly immersed themselves in the role, taking on the standard industry practice of getting screwed over by record labels and production companies.

From the epilogue of Barry Lyndon: "It was in the reign of George III that the aforesaid personages lived and quarreled; good or bad, handsome or ugly, rich or poor, they are all equal now."

That is correct, but the subterranean dodecahedron itself is merely the portal that the interdimensional lizard beings use to move between our world and the 4-dimensional hyperdodecahedron.

Not just believed, pi(n) ~ n / log(n) is the prime number theorem.

I don't know. There are empirical reasons to suspect that StarCraft uses code like this.

    void DragoonAI()
    {
        // Decide next move by reading main video buffer for random bits
        MoveDirection = Video->buf[1000];
        ...
    }

The NIST DLMF is great, but it has some deficiencies for someone who does serious work with mathematical functions.

It was created with the print edition in mind, and the web edition as a companion, rather than the other way around. Due to this focus, a lot of the content is needlessly terse.

For example, a rather useful chapter on computer algebra methods for special functions (things like holonomic functions and Zeilberger's algorithm) was written for the DLMF, but had to be discarded (in my understanding) due to page constraints on the print edition.

Also, many useful formulas are missing, and very often a case is covered as "for z < 0, combine (13.7.6) with (12.1.2) and (12.1.15)" when actually combining those formulas is half the work and the purpose of a reference is to save me trouble (and avoid potential mistakes)!

Each chapter is also written by a different author, with slight differences in the way things are organized. The good thing is that it is more than just a database of facts, with the content presented in a way that makes mathematical sense, but it can also make it more difficult to simply look up a specific fact.

My biggest gripe is that some sections of the DLMF have a very cavalier attitude when it comes to complex variables and branch cuts. A fair number of "equations" are only correct when the functions are interpreted as multivalued, and the user needs to place branch cuts the correct way. This really sucks if you need to do actual computations.

In quite a few places of the DLMF, no information about complex variables is given at all even though these are important in practice.

I often use the Wolfram Functions site (http://functions.wolfram.com/) as a complement to the DLMF, and the contrast in approach is very interesting.

The WF site is much more of a database, containing lots of more or less automatically generated entries. It is generally much more comprehensive than the DLMF, in that it allows you to look up variations and special cases of a formula in explicit form. On the other hand, it lacks most of the context and explanations provided in the DLMF.

Since the WF site content is organized completely systematically, it is very easy to find a specific formula and to compare analogous entries for different mathematical functions.

On the other hand, the WF content is harder to navigate unless you're already familiar with it. The tables of automatically generated formulas also contain a fair number of "junk" entries that no human would ever find useful.

The WF site is completely explicit about branch cuts (which makes sense since the Mathematica designers care about actual computations).

I have found some errors in the WF site, but they are quite rare. The Wolfram people actually use numerical "unit tests" for the formulas (checking identities numerically for carefully chosen values of the variables in order to verify correct use of branch cuts etc).

One of the Mathematica developers responsible for the WF site was actually present at a DLMF development meeting which took place in connection with a conference at NIST a couple of years ago, and he gave the DLMF editors a bit of a scolding about the branch cut issue, but not much happened. There's a bit of difference in philosophy: viewing a special function as a more abstract thing vs fixing concrete branch cuts.

A third interesting approach to a special functions resource is the Dynamic Dictionary of Mathematical Functions (http://ddmf.msr-inria.inria.fr/1.9.1/ddmf) which is even more automated than the WF site.

In the DDMF, a function is defined by a differential or difference equation, and all theorems and formulas are essentially generated algorithmically from first principles! Very neat. But the content that can be generated automatically this way is still quite limited compared to completely human-curated resources.

gcc already optimises away loops like for (i = 0; i < n; i++) s += i;

It wouldn't be too much of a stretch to detect and optimise away code that computes linearly recurrent sequences.

Trivia: there was about as much chemical energy in the fuel of either Boeing 767 that struck the twin towers as the gravitational potential energy released by the towers collapsing.

That's correct, but note that an electric motor is about twice as efficient as a combustion engine, reducing the factor to about 25x (at least ideally). Typical medium range aircraft burn about 3 kg fuel per km [1], so to fly 1000 km you would need about 3 * 25 * 1000 kg = 75 tonnes of batteries. This should be in the ballpark of what we can pack into an aircraft already, but I guess at least another 2x improvement is needed to make it economical (we want to haul some useful payload, not just the batteries).

[1] https://en.wikipedia.org/wiki/Fuel_economy_in_aircraft

The road markings will be clearly visible, of course, since there will be self-driving snowplows around 24/7.

That's not the issue here at all. The IEEE 754 standard does in principle make floating-point operations completely deterministic, i.e. if you do a specific sequence of floating-point operations, then the result may indeed be slightly off from the result you would expect with infinite precision arithmetic, but it should be off in just the same way every time. For example (x + 0.1) + 0.1 and x + 0.2 can give different results due to rounding, but the respective result should be constant for a given x regardless of the machine, compiler, or phase of the moon. Knowing this, there are situations where exact comparisons are appropriate.

The "bug" here is that a single operation x + 0.1 and x + 0.1 can give two different results depending on the mood of the compiler.

It's not actually a bug, because the IEEE 754 standard permits this kind of sloppiness by default. You can get stricter semantics, but you have to ask for it explicitly by setting the right compiler flags. This is why I say that the IEEE 754 standard makes floating-point arithmetic deterministic "in principle" - in practice, you have to work for it. (Changes to the rounding mode are another big issue here.)

An extra error of 1 ulp somewhere might not seem like much for your average numerical code, but it's a big deal in some situations:

* Assumptions about the precise behavior of floating-point cancellations are often used in numerical libraries, and deviations can cause disastrous loss of accuracy. For example, Kahan summation is a widely used algorithm for computing sums with increased accuracy. If compilers optimize the code too aggressively, the algorithm doesn't work and you get worse accuracy. And ironically, x87 long doubles can make general numerical calculations less accurate (not more accurate as intended) due to the double rounding issue.

* If you use floats in game logic, you might want it to behave exactly the same way on different platforms, e.g. for synchronization or replays.

* In scientific computing, you might want results to be precisely reproducible by others.

* Debugging!

Well, babies don't learn to stand and walk (and many other skills) from scratch by trial and error. The hard part of constructing a walking machine has already been solved by millions of years of evolution.

Indeed, a calf can walk within hours of being born. A human infant might need more time than a calf in part because walking on two legs is harder than walking on four, but much of the difference simply comes down to the fact that humans are born so early that a lot of predetermined brain development has not yet occurred (the muscles and bones are also too weak). The study [1] found that across varying mammalian species, walking is learned a predictable amount of time after conception (as opposed to time after birth).

There's a surely a continuum between brain functions that are completely hard wired and completely learned from scratch. I think it's accurate to say that for many functions, learning is used as a form of adaptive refinement to finalize specific predetermined neural programs. But the exact interaction between learning and pre-programming isn't well understood in most cases.

[1] http://www.pnas.org/content/106/51/21889.abstract

More precisely, stellar fusion is self-sustaining because of the immense gravitational pressure. You need around 1/10 the mass of the sun for this to be possible. In the current economic situation, it would be difficult to get funding for a fusion reactor that large.

Only if you insist on determinism :-)

It is literally a quine, viewed as a program in a language where (for example) the code consists of a regular expression and the output is the sequence of all strings matching that regular expression.

The figure I've seen cited for rhesus monkeys 93%, with cows around 80%. But why are you so concerned about genetic similarity? Isn't the more important question how sentient and capable of suffering they are? If we discovered alien beings with human-like intelligence and sentience that didn't share our DNA, would you prefer experimenting on those?

"The experiments are more of a progression than a sudden breakthrough: they are based on a decade of work in rats, Courtine says, and the monkeys reacted in very similar ways."

Well, the senior scientists who sit in evaluation committees and on editorial boards have some control over it. In many fields, only publications in "top" journals matter. If two persons then apply for the same job or grant and one has a paper in Nature while the other has a paper in Bob's Open Journal, the committee will go with the Nature paper every time.

Anecdotally, PDF.js is slow compared to native viewers and often renders documents incorrectly. And the project is five years old now. It's not bad as a fallback, but considering how important PDF files are, looking for a better solution makes sense.