Implement numba extension support

[hugohadfield]

Using the numba extension interface https://numba.pydata.org/numba-doc/latest/extending/interval-example.html We should be able to create a multivector type that numba understands and can work with directly. This would vastly improve the readability and quality of the jitted library code.

We should implement at least the operators:

• [x] a + b (gh-332)
• [x] a - b (gh-332)
• [x] a * b (gh-332)
• [x] a ^ b (gh-332)
• [x] a | b (gh-332)
• [ ] a / b
  • [x] b scalar (gh-333)
  • [ ] b multivector, general inverse
• [ ] a << b
• [x] ~a (gh-333)
• [x] -a (gh-333)
• [x] +a (gh-333)
• [x] a(b) (for integer b) (gh-336)

[moble]

Note that the old documentation specifically discussed the overloads you'd want. But I suggest making sure such a thing is still possible before going too far down this road.

Numba also has jitclass, which is almost exactly what you'd want — except that despite having lots of people (e.g., me) bugging them for a long time to add these capabilities, jitclass still doesn't support the overloads you'd really want. I went through some of those issues toward the bottom of this wiki page. The jitclass interface is really nice, and much easier to use than the awkward low-level stuff in the interval example. And they have recently added __getitem__ and __setitem__ support, with suggestions that this new code will provide a nice way forward for the other overloads. So if you don't get around to this too soon, keep an eye on jitclass's support, because that would be a much nicer approach if it worked.

[hugohadfield]

@moble I just had a go at the extension interface and I gave to agree, it is very difficult to work out what to do, here is my attempt: https://gist.github.com/hugohadfield/d8dd24869288fa5e227c598a1440dff8 In the end it is both slower than the original clifford implementation and gives incorrect values for compound functions, so overall a bit of a flop... an interesting learning experience though...

[moble]

I'm impressed that it worked as well as it did, actually. As I mentioned, I've had good experiences with jitclass, especially in terms of simplicity, but also in terms of speed. I suspect that some of that stuff you had to do manually has been streamlined out of the process, so I can imagine it will be faster with jitclass. So there's still hope for the future.

[eric-wieser]

xref #189.

Note that one of the big challenges here is handling the Layout type. Essentially we have two options:

• Pass around an opaque PyObject * pointer which is tracked from one operation to the next. This requires the overhead of runtime checks, and massaging numba into allowing such an object even in "nopython" mode. https://github.com/numba/numba/pull/3640 may help with this.

• Create a dependent type, where the numba type of MultiVector actually embeds the full layout information. Numba types are regularly pickled, so this means we need Layout objects to pickle efficiently. Right now the pickled representation of g3c.layout is 142KiB!