Hi Ludo'! Ludovic Courtès <ludovic.cour...@inria.fr> writes:
> Hi Eric, > > Eric Brown <ecbr...@ericcbrown.com> skribis: > > Are there other cases where netlib BLAS is considered more appropriate > than OpenBLAS because it’s more numerically stable? > Sorry about that, the full discussion is here: https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Linear-algebra To answer your question on other examples: I would have to do some digging for the exact details, but there was once a time when LAPACK 3.x had an SVD that would solve with QR, most expensive but would give an answer for the "most singular" of problems. It is not, however, the "published" LAPACK algorithm and is not available. (A classic case where this occurs is when throwing junk into a linear regression, whose solution is bullet-proof with the SVD. Very important for R, and many more langs and other problems such as factor analysis.) A few random points: * Good/improving compilers gfortran,gcc often make the reference lapack/blas fast enough. IIRC it is good as any optimized BLAS for small matrices. If reporting e.g. convergence issues, people converge here for apples-to-apples. * ATLAS can empirically tune for architectures that are not getting love by the OpenBLAS team. So, non-amd64 has *something* more performant than Reference LAPACK/BLAS. I've often seen distributed binaries have to choose something lackluster to satisfy older processors. * I usually use OpenBLAS because it also gives SMP. I notice it doesn't cover all the archs that Guix covers, but I think it should be default go-to unless of problems for x86_64 at least. * If memory serves, layering multiple LAPACKs came from the days when the optimized BLAS's where incomplete. People just slapped -llapack on the end to make sure that if the optimized lib didn't get it then lapack would, just that would be only at Fortran speed :-( lol Best regards, Eric
