Closes #3757 ak.array gives unexpected results on a transposed numpy multi dimensional array

[ajpotts]

Closes #3757 ak.array gives unexpected results on a transposed numpy multi dimensional array

[stress-tess]

Do we know why this fixes the error? I haven't thought about it much but if we don't have to create a copy, that's prob better right?

[stress-tess]

I mean, I guess it's not that a big of a deal bc if it was passed into ak.array was relatively small

[stress-tess]

yah it's exactly what I thought. when numpy does a transpose, it doesn't actually move any data around, it just takes the same base array in memory and switches it from column_major to row_major or vice versa (I forget which one C used vs Fortran)

>>> nda.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

>>> npa = np.transpose(nda)

>>> npa.flags
  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

>>> npa.copy().flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

When we do a deep copy, it actually allocates new memory and interprets it correctly. We don't have support for different orders with the current impl. We used to have it with arrayview but that had it's own mess of problems. I guess we could try to check if the OWNDATA flag is false and then deep copy but idk if it's worth it

[stress-tess]

I think I'll just reference this comment in the issue for future reference and approve for now. I'll leave this unresolved so other reviewers can see it bc I think it kinda interesting. And i'd like to get other opinions

[stress-tess]

nice work!! this must've been a pain to track down

[stress-tess]

I was hoping to get a second opinion on this. But it fixes the problem, so im good with merging this