BUG: No implicit setting of openmp threads

[SwayamInSync]

Can Close #168

• Removes implicit setting of threads for matmul ops

[ngoldbaum]

I'll have a couple hours to kill in the Montreal airport this afternoon and will test this and see if I can reproduce the issue.

[SwayamInSync]

I'll have a couple hours to kill in the Montreal airport this afternoon and will test this and see if I can reproduce the issue.

Thanks @ngoldbaum happy journey

[ngoldbaum]

I can reproduce the issue. I bet you can too if you set up a conda environment like this on your Mac:

micromamba create -n quad -c conda-forge python numpy
micromamba activate quad
pip install numpy_quaddtype
python -c "import numpy_quaddtype"

I'm also noticing that quaddtype now has a build dependency on an unreleased version of NumPy - which is a little annoying to work around...

I can also confirm that this PR allows me to successfully import numpy_quaddtype after installing a from-source build. Because I can't easily create an isolated build environment with an unreleased numpy version, I couldn't check if building and installing a wheel also works, but I suspect it does.

So, I think this is good. One question though: is the py_quadblas_set_num_threads function still safe to expose publicly in the Python API?

[SwayamInSync]

I'm also noticing that quaddtype now has a build dependency on an unreleased version of NumPy

Yes, we switched to the nightly releases to keep the work going in NumPy and stay here in sync

One question though: is the py_quadblas_set_num_threads function still safe to expose publicly in the Python API?

Right, I am happy to remove it as by default openmp uses all hardware threads on a system and instead of these APIs user can use threadpoolctl in case of oversubscription
Although changing them during runtime using current APIs never crashed for me

[ngoldbaum]

Nah, let's only remove it if it actually is a problem. In it goes!

Because of the new numpy version bound you should consider opening a 0.2.x maintenance branch based on 0.2.0, backport this fix, and then do a 0.2.1 release so users don't hit this issue.