Tim Holy

If you're interested in fixing these, one thing I've noted is that many people seem to think the fix is in the "offending" package. Occasionally that's true (#265 was a...

Looking at this again, one can't do this in-place because the `Axis` object's type includes the type of the range. So you'd have to create a new "wrapper." I think...

Does this already do what you want? ```julia julia> A = OffsetArray([1 3; 2 4], 0:1, -11:-10) 2×2 OffsetArray(::Matrix{Int64}, 0:1, -11:-10) with eltype Int64 with indices 0:1×-11:-10: 1 3 2...

Is the "raw" indexing time relevant? Any performance-sensitive operation is presumably in a loop, and in a loop won't the compiler [hoist](https://compileroptimizations.com/category/hoisting.htm) all the slow parts out of the loop?...

Didn't notice how long ago this came. It's been hard for folks to find time to review PRs here. Sorry for the delay.

A pull request would be welcome. The easy version is to specialize it for two OffsetArray inputs with parents that have 1-based indexing, in which case you can strip the...

I like option 2 also. You can manually call `no_view_offset` and resolve the axes how you see fit when you want 3.

I really don't think this should be fixed here. It just needs someone to go through LinearAlgebra and start generalizing the 1-based assumptions. I'm not saying that's a small job...

That's not bad; it's certain more generic than having each package that uses offset axes implement the same linear algebra functions over and over again. But fundamentally I don't see...

> unwrapping story before handing pointers to gemm!, for cases when you can? Since `gemm!` only needs pointers, you still don't have to explicitly strip the axes, as long as...