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!
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.
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.
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.