howeman

Any references to read more?

Australia has the most installed solar capacity per capita in the world, and has installed nearly 4GW of solar in the last 12 months alone. They're also making strong moves on battery storage

They started behind the curve, but they're moving quickly, relatively at least

Interestingly, "chief" is the same word as "chef" just imported from the Normans. French had a consonant shift, while English did not, and then imported the word again with the new pronunciation and spelling.

Sorry, just saw your thing below. I see your point about [2]float64 vs. [3]float64, but that still feels like mostly an operator overloading thing (I realize it isn't exclusivly). Most of the time I've dealt with that (say, [3][3]float64 vs. [2][2]float64) the contexts were different enough that generics would not have been useful because there would still have to be type switching.

I can see the argument for operator overloading being necessary, but I don't understand the argument for generics. There's basically no time I've wanted generics coding Go, except a couple times with float64 vs []float64. I also see the need for float32 vs. float64, but that's a very small use case for generics in terms of scope (we can and do autogenerate float32 code).

There's a couple of cases with float64 vs. complex128 matrices, but I have been annoyed with those silent changes in Matlab where the answer is wrong but the code continues anyway.

For small vectors and matrices the cgo overhead swamps the assembly speedups. For large vectors cache misses dominate, and the assembly doesn't matter as much. It does matter significantly for medium vectors and large matrices. In that case we provide cgo wrappers and are working on SIMD kernels.

I don't use Gonum with a webserver + large calculations so I can't definitively answer. No one has reported problems, but that could be a lack of usage. One thing though is that matrix multiplication (which is a kernel for higher-level operations) is written in a blocked format, and the code can be pre-empted on any of those blocks, so I wouldn't suspect it's a problem.

The algorithms are (basically) equivalent, and are translations from the Fortran (though row major instead of column major). As far as I know there are no major differences in the answers, though for extremely poorly conditioned matrices (1e14 or so) you shouldn't expect consistent answers across any implementation.

The performance story is complex. Typically we're the same speed on small matrices (and using Go is faster if you include the cgo overhead). We currently have significant speed penalties on large matrices (300x300 or so), but Kunde21 is working on assembly kernels for the BLAS functions to close that gap

We aren't at full feature parity, but we're pretty close. There are some big things we are missing (ODE, FFT), and we have a bunch of things they don't have (statistical distance measures being one example). We are trying to be pure-go, so it's not at simple as providing a wrapper API. Working on it though!

General math use, like numpy/scipy.

Oh right, of course, because you're iterating the distribution. Duh.

And yea, mat mul is not N^3 theoretically, but most implementations are. I've heard that some (mkl maybe) are 2.8, but haven't had someone point code to me. My personal attempts at implementing Strassen were slower than a tuned N^3 implementation, at least for matrices that fit into memory.

Why do you say it will scale far beyond? Mat mul is N^3 as is eigenvalue solving.

It's actually the second highest eigenvalue. The highest eigenvalue is always 1 for stochastic matrices.

Go has a large chuck of numpy/scipy stuff github.com/gonum

Though, congregationalists are one of the most pro LGTB churches and have been for a long time

How much code do you have that compilation is 3 minutes?

Removing compiling issues, keeping everything in one language. Plus, when you do, you find bugs. We've found a bunch in lapack implementing gonum (godoc.org/github.com/gonum/lapack)

In the beginning we were still trying to figure out what we wanted. There was a lot of really free-form changes, and it was easier to keep those sweeping changes isolated from one another. We're planning to do a couple breaking changes at once at some point, and one of those is likely moving everything into a single repo.

Wow! That's a ton of stuff. I wish you were working with us at gonum. Can we work together?

Interactivity can be an important feature for scientific programming, but so is having correct underlying algorithms that are implemented in a clean, composable way. Go is a good language for such implementations.

> Go doesn't have a nice REPL like IPython, and it never will.

https://github.com/gopherds/gophernotes

Yep

Actually, it's mostly assembly (depending on the particular implementation). Lapack is Fortran though.

Either sort.Interface or a type that implements sort.Interface

Or http://senseis.xmp.net/?GoProverbs

AlphaGo does do a tree search as you say, but the "value" of the stopping node is half the neural network you mention, and another half performing Monte Carlo with medium strength 'players' (2d amateur). These 'players' are really a quick version of the priority network that figures out which moves to play in the first place.

There's a really nice video series on fluid mechanics if you're okay with old-style videos. The one on low Reynolds number is here https://www.youtube.com/watch?v=B9XL_OOwJ14&index=7&list=PLC...

In particular, there is a nice illustration of "inertia doesn't matter" at 15 minutes.

Is there any public "how to" about Gerrit? I've interacted with it a few times for Go codereviews, but not frequently enough to get comfortable. Really simple things like finding the "submit comments" button I have to spend five minutes finding every time.

Of course, you frequently don't want operator overloading for matrix multiplication. Avoiding allocations is a big deal for speed, and so c.Mul(a,b) is often the right answer even with operator overloading.

Generics aren't likely to be fixed any time soon, but it's not that the authors aren't listening. Here's Russ Cox's reply on the issue

https://news.ycombinator.com/item?id=9622417

> There might be some exotic cases where genetic algorithms are actually the best solution, but nobody knows that.

Actually, No Free Lunch guarantees that such cases exist.