Trouble interacting with numba

[OracPrime]

I'm working with Python on Windows, managed via Anaconda. I've tried both 3.6.4 and 3.7.3 and get the same problem. Just these three lines:

import numba import awkward import awkward-numba

give me an error with the following traceback:

Traceback (most recent call last): File "", line 1, in File "d:\Anaconda3\lib\site-packages\awkward\numba__init__.py", line 7, in from awkward.numba.array.base import NumbaMethods File "d:\Anaconda3\lib\site-packages\awkward\numba\array\base.py", line 10, in class NumbaMethods(object): File "d:\Anaconda3\lib\site-packages\awkward\numba\array\base.py", line 11, in NumbaMethods NUMBA_DEFAULTTYPE = numba.from_dtype(numpy.float64) File "d:\Anaconda3\lib\site-packages\numba\numpy_support.py", line 90, in from_dtype if dtype.fields is None: AttributeError: type object 'numpy.float64' has no attribute 'fields'

Numba 0.26.2 Awkward 0.12.10 Awkward-numba 0.12.10

Any suggestions?

[jpivarski]

I started implementing this awkward-numba in February, then realized that it would essentially be another whole implementation and I can't maintain both. Instead of two side-by-side implementations, I'm working on a single reimplementation that exposes the same algorithms to Python and Numba: awkward-1.0.

As you can see from the status, I'm at the level of getting basic jagged arrays (ListOffsetArray) in C++, Python, and Numba from a shared implementation, and this will be the basis for building an awkward-array that can be reliably used in Numba.

For now, the original awkward-numba is available only as an experiment, and I need to not maintain that in order to develop the version that will work. Sorry!

[OracPrime]

Thanks for the extremely rapid feedback. Given that ListOffsetArray is the only one I was looking for (if I've understood correctly: effectively list of list of list of... ), do you think it's worth taking a punt with awkward-1.0 yet? This is for investigative code, not production use.

[jpivarski]

Even at that level, probably not yet. I'm struggling through what I know to be the most definitive part: __getitem__. The class structure will be heavily influenced by what information I'll need to pass down to implement this method.

That said, the master branch will always be clean, and the tests demonstrate what features are currently possible (I've taken to naming tests after pull requests, so you know which are the new ones, though old ones necessarily change to keep up with changes in interface). It's deliberately feature-poor until the class structure is figured out, so there's __getitem__ (for int and slice) and __iter__, but not much else.

[OracPrime]

OK. Good luck! I look forward to trying the result.