Yeah, that is what I mean. I will let someone else decide further, but I think the transpose may need to be a bit more complicated. To figure that out/test it, can you add a test for multiplying larger then 2D arrays?

My understanding is that this isn't intended for public consumption as it only works on 2D arrays or smaller just as cblas_matrixproduct. Instead, there is a PyArray_InnerProduct, which is intend for use in the C API and is bound to np.inner in the Python API.

This only gets called in one place (

Ah, right. Frankly, I would much prefer if we can do it for PyArray_InnerProduct making it just call PyArray_MatrixProduct2. Then remove the whole cblas_innerproduct function. Though I am not sure it makes sense, my guess would be it does.

It looks like there are some einsum tests that also give inner 3D arrays, but I don't know that this is the best way to test inner on these cases by comparing it to the much more complex einsum. I can certainly add some. ( https://github.com/jakirkham/numpy/blob/e72e1510d892ce4464cf102000e89582327953a0/numpy/core/tests/test_einsum.py#L262-L275 ).

Other things this probably needs are some benchmarks as I am claiming one can now get a speedup with inner in some special cases.

Ah, right. Frankly, I would much prefer if we can do it for PyArray_InnerProduct making it just call PyArray_MatrixProduct2. Then remove the whole cblas_innerproduct function. Though I am not sure it makes sense, my guess would be it does.

It is probably removable, but what I liked about your original proposal (at least how I read it) is everything stays pretty much the same in terms of how everything builds. Also, how many, which, and where functions are remains the same. As soon as we start messing with that, we open ourselves up to spending time hunting down potentially weird build errors. At present, this just works.

Well, look at MatrixProduct2 ;), it is a monster of annoying stuff and all that is needed to call it from inner is transposing the last two axes of op2 (if op2.ndim >= 2). The added complexity is only that the transpose is more complicated because you cannot pass in NULL. Other then that, you just remove more complexity. Note that the function you changed can be removed completely, it is not public.

It would be nice if there was a PyArray_RollAxis.

Well, I don't know, you probably have to go way back to figure that one out ;). That is why I would like it refactored away. You save a single tranpose (array creation) for all I figure.

Sorry, I realized I was asking a question that was basically becoming "why do we have numpy.dot and numpy.inner?" and decided I should just be quiet lest this gets derailed.

BTW, did you see this ( #5859 )?

So, if I make this simple change ( jakirkham@2288e34 ), I get a segmentation fault in the test suite. Is there something that I am doing wrong here? I'm not very familiar with the C API so I wouldn't be surprised if I am. I just need a few pointers.

Can you do me the favor and try to refactor all of PyArray_Inner? At least to me doing the transpose specifically in this subfunction seems half baked. Doing the full transpose should not be too difficult, see for example https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/mapping.c#L135 for a "complex" Transpose operation, but it gives you the idea that you can just iterate and set all ndim (if ndim >= 2), and then switch the last two ndim around.

So, I actually did that too. Though I have not pushed it to the PR yet.

I am struggling with a segmentation fault there, as well. Here is the commit ( jakirkham@8f5464c ). Any pointers on why the segmentation fault occurs in either case would be helpful.

Tried to add some tests for the exception, but they fail USE_DEBUG=1 only due to some issue with the exception. Not really, sure what is going on there. Thought it might be related to this ( http://bugs.python.org/issue20500 ), but that is suppose to be fixed. Any pointers anybody has would be helpful. Maybe related to this ( #6741 ), but I doubt it.

So, I have removed the changed exception as it appears to be somewhat controversial and it is in a different PR ( #6987 ) with exception tests. I have also removed the exceptions tests as they seem to have issues that at the moment I cannot seem to figure out and placed them in another PR ( #6988 ). If we can get these working, I am willing to combine them back into this PR. However, I don't want this PR's fate to be determined by trying to come up with acceptable solutions to these more minor issues.

Looks good to me, did you check there are tests for 3-dim arrays, or could you add them if they don't exist?

There are some, but they are comparing einsum to inner. Though we probably should have some tests for inner that don't rely on another function (especially a more complex one) to determine success, which I am adding. Also, probably could use at least one syrk vs. gemm test.

Yes, they went in the PR ( #6986 ), which is already merged. This PR has been rebased on master after those commits were added so includes them.

Figured out the issues with type exceptions thanks to help from @seberg and @charris. As they are now working, I have brought that PR ( #6988 ) back into the history of this PR.

Failures on AppVeyor ( #6991 ) had not previously occurred for this PR with exception of the segmentation fault issue (also happened on Travis), which has since been resolved. I believe these to be unrelated to the content of this PR.

As AppVeyor is merging with master, which is broken, it is currently failing the tests there. So, I ran my own AppVeyor build without this merge (this is rebased on a commit on master before the bad commit) and it looks like it checks out ( https://ci.appveyor.com/project/jakirkham/numpy/build/1.0.4 ).

Thanks @jakirkham . The cblasfuncs.c could use some style fixes, but that isn't new here.

Thanks!

Thanks everyone.

Alright, @charris, I'll try to look at this at some point soon.

The benchmark shows the syrk speedup. ( https://pv.github.io/numpy-bench/#bench_linalg.Eindot.time_inner_trans_a_a )

Very nice!

An attempt at fixing the style errors, @charris. ( #7038 )