Just a comment, supporting a library that is bsd 3 clauses could help to higly reduce the compilation problem like what we have with blas. We could just include it in numpy/download it automatically or whatever to make the install trivial and then we could suppose all users have it. Deadling with blas is already not fun, if new dependency could be trivial to link to, it would be great.
Fred On Fri, Mar 14, 2014 at 8:57 AM, Gregor Thalhammer <[email protected]> wrote: > > Am 14.03.2014 um 11:00 schrieb Eric Moore <[email protected]>: > > > > On Friday, March 14, 2014, Gregor Thalhammer <[email protected]> > wrote: >> >> >> Am 13.03.2014 um 18:35 schrieb Leo Mao <[email protected]>: >> >> > Hi, >> > >> > Thanks a lot for your advice, Chuck. >> > Following your advice, I have modified my draft of proposal. >> > (attachment) >> > I think it still needs more comments so that I can make it better. >> > >> > And I found that maybe I can also make some functions related to linalg >> > (like dot, svd or something else) faster by integrating a proper library >> > into numpy. >> > >> > Regards, >> > Leo Mao >> > >> Dear Leo, >> >> large parts of your proposal are covered by the uvml package >> https://github.com/geggo/uvml >> In my opinion you should also consider Intels VML (part of MKL) as a >> candidate. (Yes I know, it is not free). To my best knowledge it provides >> many more vectorized functions than the open source alternatives. >> Concerning your time table, once you implemented support for one function, >> adding more functions is very easy. >> >> Gregor >> > > I'm not sure that your week old project is enough to discourage this gsoc > project. In particular, it would be nice to be able to ship this directly as > part of numpy and that won't really be possible with mlk. > > Eric > > > > Hi, > > it's not at all my intention to discourage this project. I hope Leo Mao can > use the uvml package as a starting point for further improvements. Since > most vectorized math libraries share a very similar interface, I think the > actual choice of the library could be made a configurable option. Adapting > uvml to use e.g. yeppp instead of MKL should be straightforward. Similar to > numpy or scipy built with MKL lapack and distributed by enthought or > Christoph Gohlke, using MKL should not be ruled out completely. > > Gregor > > > > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
