On Tue, 6 Oct 2015 10:07:13 -0700
Nathaniel Smith <n...@pobox.com> wrote:
>
> And how are you getting at them? Are you just relying the way that on
> ELF systems, if two libraries are loaded into the same address space
> then they automatically get access to each other's symbols, even if
> they aren't linked to each other? What do you do on Windows?
Well it seems to work on Windows too, thanks to
numpy.distutils.misc_util.get_info('npymath').
Under Windows, I seem to have a
"<Python root>\site-packages\numpy\core\lib\npymath.lib" static library,
and there's also a "npy-pkg-config" subdirectory there with some INI
files in it. Hopefully you know better than me what this all is :-)
> > And, of course, we would also benefit from the CBLAS functions (or any
> > kind of C wrappers around them) :-)
> > https://github.com/numpy/numpy/issues/6324
>
> This is difficult to do from NumPy itself -- we don't necessarily have
> access to a full BLAS or LAPACK API -- in some configurations we fall
> back on our minimal internal implementations that just have what we
> need.
I'm thinking about the functions exposed in
"numpy/core/src/private/npy_cblas.h".
My knowledge of the Numpy build system doesn't allow me to tell if it's
always available or not :-)
> There was an interesting idea that came up in some discussions here a
> few weeks ago -- we already know that we want to package up BLAS
> inside a Python package that (numpy / scipy / scikit-learn / ...) can
> depend on and assume is there to link against.
>
> Maybe this new package would also be a good place for exposing these wrappers?
Yeah, why not - as long as there's something well-known and
well-supported to depend on. But given Numpy is a hard dependency for
all the other packages you mentioned, it may make sense (and simplify
dependency management) to bundle it with Numpy.
Regards
Antoine.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
