change to dynamic linking and add interface and threading layers

[vtavana]

resolves IntelPython/mkl_fft#165

Main branch

import numpy as np, mkl_umath
n = 2**31
data = np.ones(n)
mkl_umath.absolute(data)
# Intel oneMKL ERROR: Parameter 1 was incorrect on entry to vdAbs.
# array([0., 0., 0., ..., 0., 0., 0.], shape=(2147483648,))

This branch

import numpy as np, mkl_umath
n = 2**31
data = np.ones(n)
mkl_umath.absolute(data)
# array([1., 1., 1., ..., 1., 1., 1.], shape=(2147483648,))

[ndgrigorian]

In general I don't see a problem with this change, but changing a dependency is a pretty big tweak.

@ekomarova @AndresGuzman-Ballen is there any way Intel NumPy tests can be run with this branch to make sure it doesn't introduce any major failures?

[AndresGuzman-Ballen]

@ndgrigorian I suppose I could point mkl_umath's commit in numpy-2.2.5 branch to this branch, but I'd prefer doing that after I can get all subpackages to build and pass tests in our CI

[ekomarova]

This PR does not break testing with Intel Numpy 2.2.5. All checks are green. I will also check v1.26.4

[ekomarova]

@ndgrigorian I see some problems in build/tests in numpy 1.26.4. Could you please take a look at it here https://github.com/intel-innersource/libraries.python.intel.condarecipes.numpy-recipe/pull/152?

[vtavana]

@ndgrigorian I see some problems in build/tests in numpy 1.26.4. Could you please take a look at it here intel-innersource/libraries.python.intel.condarecipes.numpy-recipe#152?

@ekomarova To fix build failure you need to pin setuptools >= 77

[vtavana]

Linux test failure is because of tolerance, I think it should be patched to fix.

FAILED core/tests/test_umath.py::TestPower::test_power_float - AssertionError:
Arrays are not almost equal to 7 decimals
unary offset=(0, 0), size=8, dtype=<class 'numpy.float32'>, out of place
Mismatched elements: 1 / 8 (12.5%)
Max absolute difference: 2.3841858e-07
Max relative difference: 9.7333974e-08
x: array([0.       , 0.9999999, 1.4142134, 1.7320508, 1.9999999, 2.236068 ,
2.4494896, 2.6457512], dtype=float32)
y: array([0.       , 1.       , 1.4142135, 1.7320508, 2.       , 2.236068 ,
2.4494898, 2.6457512], dtype=float32)

FAILED core/tests/test_umath.py::TestAVXUfuncs::test_avx_based_ufunc - AssertionError:
Arrays are not equal
Mismatched elements: 1 / 2 (50%)
Max absolute difference: 4.7683716e-07
Max relative difference: 6.150229e-08
x: array([2.410054, 7.75316 ], dtype=float32)
y: array([2.410054, 7.75316 ], dtype=float32)

[AndresGuzman-Ballen]

Rather than tweak the precision, what if the numpy PR just include this? https://github.com/intel-innersource/libraries.python.intel.condarecipes.numpy-recipe/blob/2.2.5/patches/add_precision_flags.patch

[AndresGuzman-Ballen]

@ekomarova in case you're curious how I came to that conclusion, this is some context: #73

[vtavana]

Windows failure are not related to this PR, they are related to #73
Does numpy-1.26.4 works with main branch of mkl_umath? or we had not tested that recently?

[AndresGuzman-Ballen]

I think numpy 1.26.4 wasn't tested recently with recent mkl_umath changes. I'll push some tweaks so that way the numpy 1.26.4 PR works.

[napetrov]

should it be ilp64 vs defailt lp64 used in numpy/scipy?

[napetrov]

Or might be to put this differently after reading initial issue - how this would work and what implications we would get because of ILP64? Compatibility with stock numpy? Performance and memory consumption implications because of longer int?
Also how does this works currently in case of stock numpy as they use LP64 by default and not facing reported problem?

[vtavana]

I chose ilp64 because MKL_INT is long long (8 bytes) from this table while lp64 is int (4 bytes).

However, I tested with lp64 right now and it works with it as well.

[napetrov]

side question - why dpcpp compiler referenced here as there is no sycl us in mkl_umath?

[ndgrigorian]

The build instructions have been recommending using the Intel LLVM compiler for some time now—mostly to have a working C compiler, especially one we test with

[AndresGuzman-Ballen]

@vtavana how strange...I saw a Windows failure for the ldexp function here when the changes from here seem to be included. Is the ilp64 PR introducing this issue again?

[vtavana]

@vtavana how strange...I saw a Windows failure for the ldexp function here when the changes from here seem to be included. Is the ilp64 PR introducing this issue again?

I believe there was a change in #73 that is not needed and should be reverted. I created a new PR to revert it #77