The Navier-Stokes have no problem with stall. The problem is that the Navier-Stokes equations are hard to solve (to use them predictively). The Euler equations do not account for turbulence at all. The Euler equations are good at modeling pressure, which is good for lift and shocks, but does not predict drag, and does a bad job when stall occurs. The RANS equations (a simplified form of the Navier-Stokes equations), do account for tubulence, but one needs a good turbulence model. No turbulence model handles stall well on a broad spectrum of cases, but the RANS equations do do pretty well for attached boundary layers (loosely, when shapes are "aerodynamic" -- like an airplane rather than like a truck or sphere).
Go sort of does this, though on longer timescales. Developers are at "tip". Actual releases are every 6 months, and before the release there is always at least one release candidate, and sometimes an actual beta.
Just as a clarification, the proposals are to add multi-dimensional slices (dynamically sized arrays). This statement is splitting hairs, but a Matrix is a container for numeric types that can do things like multiply and have a cholesky decomposition. A multi-dimensional slice is just a container for whatever you want. Such a container is very useful for matrices, but a package would still have to turn a multi-dimensional slice into a Matrix in order to add methods like Add.
As of at least a year ago, their are bindings for the BLAS library of your choice (github.com/gonum/blas), which are used in many parts of the matrix package (github.com/gonum/matrix/mat64). As of a week ago, there are bindings for the Lapack implementation of your choice (github.com/gonum/lapack). These have not yet been worked in with matrix, but will be eventually (PR welcome!).
It's complicated. Most rulesets (AGA, New Zealand, I believe chinese) say "resume the game". The Japanese ruleset is a lot more complicated.
I still don't see your argument. Humans and humans are capable of agreeing on a score with those rulesets. Computers are also capable of following the ruleset and agreeing on the score. Computer vs. human games are not playing by a different ruleset. By that ruleset, the game is over when both sides pass.
I am one of the developers, and at the moment I wouldn't use it for critical stuff. We would like it to be good (not just functional) and that takes time. We are not in "1.0" stage yet, and we make backward incompatible changes from time to time. Specifically, if the proposal for tables is accepted, the package will change a lot (and it will be awesome). The CBLAS package should work well, and I believe all of the goblas functions that are there have good tests. In my opinion, Mat64 needs a lot of work before it is a "premiere" package (a bunch is missing and a bunch is slow). That said, I use it in my work and many parts of it are good. We are interested in making it better, but it's entirely volunteer and it all takes time. It would be great to have people providing code/documentation/bug reports, so I encourage you to use it in non-critical stuff.
I think he was suggesting that you wrote the compiler to use only the parts of C that could be converted to go, not that C was written to be convertible to go.
They aren't writing a general tool from C to Go. They are writing a specific tool to convert the compiler from C to Go. They will then make major modifications, but it's much easier to do that from working Go code than from scratch.
I think that's basically it. If you want to do a lot of work you can do somethings with cross validation (see which parameters perform the best), but that's a form of automatic try/fail
Is this also what is used to enforce academic standards (i.e. each student doing individual work)? I've heard CS lodges the most official complaints of any department.