Hi, On Fri, Apr 11, 2014 at 9:03 AM, Nathaniel Smith <[email protected]> wrote: > On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner <[email protected]> wrote: >> a discussion about OpenBLAS on the octave maintainer list: >> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746 > > I'm getting the impression that OpenBLAS is being both a tantalizing > opportunity and a practical thorn-in-the-side for everyone -- Python, > Octave, Julia, R. > > How crazy would it be to get together an organized effort to fix this > problem -- "OpenBLAS for everyone"? E.g., by collecting patches to fix > the bits we don't like (like unhelpful build system defaults), > applying more systematic QA, etc. Ideally this could be done upstream, > but if upstream is MIA or disagrees about OpenBLAS's goals, then it > could be maintained as a kind of "OpenBLAS++" that merges regularly > from upstream (compare to [1][2][3] for successful projects handled in > this way). If hardware for testing is a problem, then I suspect > NumFOCUS would be overjoyed to throw a few kilodollars at buying one > instance of each widely-distributed microarchitecture released in the > last few years as a test farm... > > I think the goal is pretty clear: a modern optionally-multithreaded > BLAS under a BSD-like license with a priority on correctness, > out-of-the-box functionality (like runtime configurability and feature > detection), speed, and portability, in that order.
It sounds like a joint conversation with R, Julia, Octave team at least would be useful here, Anyone volunteer for starting that conversation? Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
