If you don't do this as a static (and shared for BLAS/LAPACK dependency) library, other C code can't use it. That's why it is just a header file in common utils right now for sqrtm and eventually for others.

Let's do it in a "jpeg loading" way: here's an extension module, self-contained. Once it has some more usage, we figure the common parts and make them shared (TBD if via a static library or a common header)

why is this namespace _numpymath required? Can't we not template using the regular dependencies to NumPy without our own extra boilerplates?

The whole _npymath.h header exists mainly to cover for what numpy/npy_math.h lacks, and because I work here with npy_cdouble directly without converting to C/C++ complex. This way there is no need forreinterpret_cast or anything.

Or is the question why it is in a namespace at all? Well, using namespace in a header is not a good practice indeed, so I should probably remove the namespacing. Or, better, put everything into a namespace.

No unfortunately, this is basically to transpose a matrix in smaller chunks that fits into L1 cache to reduce the cache misses.

At least in theory. I think we should unroll these to 8 for reals and 4 for complexes.I need a proper godbolt session to get a feeling for what compilers are choosing to do. I'll get to it eventually.

dcopy is BLAS' memcpy. They do different things.

My impression was that incx, incy arguments are essentially strides. But if not, great, I'll remove the comment.

I don't get your comment about not using OOP. This is pretty much a class with a single method. Instead of loop optimizations now you are converting it into a Python generator and yielding a slice here if I can read C++ correctly.

Err, no, it's exactly equivalent to the sqrtm looping. Even the names are the same :-).
The usage is (https://github.com/scipy/scipy/pull/22838/files#diff-4c915d9c644759eaa646244756e388af6a0d49f33d6546864b5cff09ce056431R264

iter_data_t iter_data(array_object);    // grab shape/strides, compute the offset pointer

for (npy_intp idx=0; idx < iter_data.outer_size; idx++(
    iter_data.copy_slice(idx, buffer);              // copy slice `idx` into `buffer`
    ...
) 

The only difference to sqrtm version is that here I transpose into the F order right away instead of copy first, swap_cf immediately after.

If having get_buffer as a method of a struct bothers you, no problem, I'll rewrite it as a free function
copy_slice(iter_data, idx, buffer). Will that cover your concerns?

This is a class instance here. I really don't see the complication helping us here a class with a single method is pretty much a function. Still missing the call to gecon though.

I understand the temptation but this is clearly a C++ class. We need to justify the need for a class within us first.

If it is always a single instance then this is just unnecessary code making things complicated and holding bunch of variables together. I can't reuse anything inside this class it is just wasted memory. Say, I already have a larger integer array, I want to use it with a gesv call. Now you are taking away that possibility with this or making it 10x harder to achieve because then I have to overwrite this with dependency injection or whatever the terminology is.

If we had 100 instances of this entity, like a computer game with 100 characters, yes by all means let's class'ify it but for single instances Class usage is an abstraction that carries the burden of proof. Independent from C++, we also have such code in Python, equally difficult to keep track of. The most recent I'm working on is _arpack.py with three big classes and single instances. It is really not a great experience I can tell you to troubleshoot.

We just need three consecutive lapack calls for getrf/gecon/getri. Look at all the preparation code that goes into it. And I can't import it to a C code if we have to.

Well, it's just a bag holder of LAPACK arguments, so instead of

getrf(&n, &n, a,  &lda, ....)

you initialize the lda (once) and do getrf(getrf_data). To me, these have two advantages:

• cut down on having to finger count the LAPACK arguments (trivial for getrf, fun when there are 11 or so).
• when implementing, say, LU, I don't need to copy-paste the LAPACK call and double-check the variables. It's already done in the constructor.

The memory argument I get, but frankly, I don't see how it's relevant here. First, how on earth are you going to end up with a 100 simultaneously active lapack calls. This is a local variable, nothing more. Note that array allocations are separate.
Second, even if you end up with, say, 100 threads, each of which is running a LAPACK computation---so that you do have 100 getrf_data variables, you also have done 100 mallocs for the work arrays, and 100 matrices to factorize. Surely you have bigger issues with memory/CPU switching then 100 copies of five int variables.

So it is all down to stylistic preferences ISTM. From where I stand, it is not a deal-breaker, so how about either,

• rename the constructor into init_getrf function, or
• ditch the structs and just call ?getrf(...) manually.

Would either of these address your concerns?

Let's do it in a "jpeg loading" way: here's an extension module, self-contained. Once it has some more usage, we figure the common parts and make them shared (TBD if via a static library or a common header)

The whole _npymath.h header exists mainly to cover for what numpy/npy_math.h lacks, and because I work here with npy_cdouble directly without converting to C/C++ complex. This way there is no need forreinterpret_cast or anything.

Or is the question why it is in a namespace at all? Well, using namespace in a header is not a good practice indeed, so I should probably remove the namespacing. Or, better, put everything into a namespace.

My impression was that incx, incy arguments are essentially strides. But if not, great, I'll remove the comment.

Err, no, it's exactly equivalent to the sqrtm looping. Even the names are the same :-).
The usage is (https://github.com/scipy/scipy/pull/22838/files#diff-4c915d9c644759eaa646244756e388af6a0d49f33d6546864b5cff09ce056431R264

iter_data_t iter_data(array_object);    // grab shape/strides, compute the offset pointer

for (npy_intp idx=0; idx < iter_data.outer_size; idx++(
    iter_data.copy_slice(idx, buffer);              // copy slice `idx` into `buffer`
    ...
) 

The only difference to sqrtm version is that here I transpose into the F order right away instead of copy first, swap_cf immediately after.

If having get_buffer as a method of a struct bothers you, no problem, I'll rewrite it as a free function
copy_slice(iter_data, idx, buffer). Will that cover your concerns?

Well, it's just a bag holder of LAPACK arguments, so instead of

getrf(&n, &n, a,  &lda, ....)

you initialize the lda (once) and do getrf(getrf_data). To me, these have two advantages:

• cut down on having to finger count the LAPACK arguments (trivial for getrf, fun when there are 11 or so).
• when implementing, say, LU, I don't need to copy-paste the LAPACK call and double-check the variables. It's already done in the constructor.

The memory argument I get, but frankly, I don't see how it's relevant here. First, how on earth are you going to end up with a 100 simultaneously active lapack calls. This is a local variable, nothing more. Note that array allocations are separate.
Second, even if you end up with, say, 100 threads, each of which is running a LAPACK computation---so that you do have 100 getrf_data variables, you also have done 100 mallocs for the work arrays, and 100 matrices to factorize. Surely you have bigger issues with memory/CPU switching then 100 copies of five int variables.

So it is all down to stylistic preferences ISTM. From where I stand, it is not a deal-breaker, so how about either,

• rename the constructor into init_getrf function, or
• ditch the structs and just call ?getrf(...) manually.

Would either of these address your concerns?