your title is more eye-catching in addition to more accurate.

I guess the speed of APL is comparable to python rather than Fortran?

If by Python you mean numpy, then yes.

Project Euler is a good place for teenagers to start learning programming, better than the routes of game or website design.

But LINQ is too slow comparing to vanilla SQL.

When you look at the GPS estimated time of arrival, or check the current MPG or mile left for your car.

Kalman filter is a natural example of iterative algorithm. Writing it in Fold does not gain much.

I think this is overdone and does not help the intuition. two things: (1). the first step of transposing the second matrix 90 degree is unnecessary and confusing. A row vector and a column vector are different. This step confuses the two. (2). All the final elements are independent and should be calculated in parallel, the stepped anime is not necessary and does not reveal this basic fact.

If you compose two linear transformations into one step, and apply distributive property, you get the matrix multiplication rule.

http://math.stackexchange.com/questions/31725/intuition-behi...

stock price is about the sum of all future cash flow. not current profit level. you can have different forecasts, but you cannot say the act of making forecast itself is nonsense.

Because Microsoft implemented random_device correctly while MingW / GCC hasn't?

Its a bug in MingW. Which isn't a big deal because Microsoft Visual Studio Community Edition is an excellent IDE and compatible with OSS projects now.

Could you point to the gcc bug? Note: the standard does not require a non-deterministic random_device, at least C++11 doesn't, so the behaviour as described in the stackoverflow link would be allowed.

There are a lot of things the C and C++ standards allow implementations to do, such as making int 16 bits, using one's complement for signed integers, (in C) only making the first 31 characters of identifiers significant, (in C++) not allowing any identifiers longer than one character, except those in the standard library, et cetera. This is because they are designed to be portable to a wide variety of compilers and target devices which might have limits that weren't envisioned at the time of writing the standard. Doesn't mean it's a good idea to write absolutely pathological implementations for no real reason other than laziness...

>This is because they are designed to be portable to a wide variety of compilers and target devices which might have limits that weren't envisioned at the time of writing the standard.

That's not really the case here, is it? If anything the bug is in the standard.

> std::random_device may be implemented in terms of an implementation-defined pseudo-random number engine if a non-deterministic source (e.g. a hardware device) is not available to the implementation.

Windows has a non-deterministic source (IE: The function CryptGenRandom). Therefore, this is a bug in MingW's implementation. CryptGenRandom is hard to use, but that's no excuse for MingW's developers to be lazy.

Pointing at a "mistake" in the spec when the intent of the spec is extremely clear is laziness. Pure and simple.

I'd think the autoseed proposal in this post addresses that problem.