<p>It seems we missed the opportunity to wish gonum (and the gonum-dev mailing list) its 3rd birthday!</p>
<p><a href="https://groups.google.com/forum/#!topic/gonum-dev/4_SrZsoMeBs">https://groups.google.com/forum/#!topic/gonum-dev/4_SrZsoMeBs</a></p>
<p>can you think of something gonum ought to have and doesn't yet?
or better yet: can you think of something you could do for and contribute to gonum, as birthday gift ? :)</p>
<hr/>**评论：**<br/><br/>BESSEL_DYSFUNCTION: <pre><p>gonum should have curve fitting routines. (Unless it already does and I've missed them). mathext should be made larger and shouldn't segregate the different special functions by into subpackages (like it does for Airy). It would be nice if so many of the matrix functions didn't require internal heap allocations (or at least they do with the outdated version I'm still using: maybe that's also changed).</p>
<p>I've been meaning to contribute 1D, 2D, and 3D spline code for a while (I have it written and tested. Need to think more about interface tradeoffs). I also am probably going to end up implementing a fitting routine for something I need soon. Any contributions I make probably won't be until a month or two from now: I'm pretty much underwater with work right now ;).</p></pre>howeman: <pre><p>It has linear regression via Solve, but that's it. I agree it should have more detailed fitting algorithms.</p>
<p>mathext can still be in flux, the discussion was that it should be broken up. Feel free to comment if you have good reasoning. <a href="https://groups.google.com/forum/#!topic/gonum-dev/Peu9M-j0O7w" rel="nofollow">https://groups.google.com/forum/#!topic/gonum-dev/Peu9M-j0O7w</a></p>
<p>I'm not sure I agree on the matrix functions. Of course it would be nice if they didn't allocate. In my opinion it's really nice that input matrices aren't modified rather than needing to memorize which functions modify and which don't. Frequently this requires an allocation and a copy, which I think has less cost than the potential errors otherwise. We try to mitigate this with an allocation pool, and the user can frequently mitigate this by having independent receivers. Of course, if there are unnecessary allocations you see then file a bug/PR. </p>
<p>Spline code would be appreciated, just make sure you open a discussion on gonum-dev first. We haven't figured out how all of the fitting stuff should work yet.</p></pre>BESSEL_DYSFUNCTION: <pre><p>Oh, if there's already been an extended discussion on the pros and con, I'm sure my views have already been brought up. They're not particularly deep.</p>
<p>I've looked at the newer call signatures. These are much better than the ones I was used to using. There are still some internal allocations (which are mostly necessary given the call signatures), but it's a vast improvement. Spent some time this afternoon updating a bunch of gross computational geometry code to use the new versions. (And in doing so found out that my cluster was still running Go 1.3 when it crashed while compiling gonum/internal).</p>
<p>(Although, to clarify, my problem with the allocations is not performance, it's heap fragmentation.)</p>
<p>Yes, some thought definitely needs to be put into these types of interfaces. The spline stuff in particular is currently written with functional options, so it very much needs to changed to be consistent with the way the rest of gonum is written.</p></pre>sbinet: <pre><p>wrt your spline code: feel free to send a PR or to start a discussion on gonum-dev, even if it is not completely finalized.
I have found having somebody else look at the code or confront ideas to be a huge benefit wrt the final "product".</p></pre>howeman: <pre><p>Gonum needs:</p>
<ul>
<li><p>ODE Solver (vladimir is working on this)</p></li>
<li><p>Constraint-based optimizer (Simplex PR is posted as a start)</p></li>
<li><p>Global optimization (GAs, etc.) (PR discussion started as well)</p></li>
<li><p>FFT (I don't know of anyone working on that)</p></li>
<li><p>Lapack-backed eigenvalue decomposition (we have symmetric eigenvalues). Vladimir is working on the port </p></li>
<li><p>Additions to the distributions package, most notably Beta distribution (which requires additions to mathext), but others like Rayleigh would be nice.</p></li>
</ul></pre>BESSEL_DYSFUNCTION: <pre><p>Oh, I hadn't realized there was no FFT.</p>
<p>At least there are a couple of unaffiliated libraries which provide support for that.</p></pre>Apofis: <pre><p>Regarding eigenvalues ... Is there no QR iteration implementation for calculating eigenvalues? This algorithm is the best for this job. It is also used as most robust for finding roots of polynomials - simple compute eigenvalues of companion matrix.</p></pre>howeman: <pre><p>There is an implementation there now, but it is not the fastest or most robust algorithm. As you mention, iterated QR is a good algorithm -- the one lapack uses. Here is the call graph for the algorithm </p>
<p><a href="http://www.netlib.org/lapack/explore-html/d9/d8e/group__double_g_eeigen_ga8ec1625302675b981eb34ed024b27a47_cgraph_org.svg" rel="nofollow">http://www.netlib.org/lapack/explore-html/d9/d8e/group__double_g_eeigen_ga8ec1625302675b981eb34ed024b27a47_cgraph_org.svg</a></p>
<p>As you can see, it is hours and hours of work to implement such an algorithm, especially with tests along the way to ensure correctness.</p></pre>
