Signature inspection with jitclass

Numba Support: How do I do ...?
1

I’ll freely admit that I’m out of my depth here, but I’m attempting to adapt slumba code to a current version of numba (0.51.2). The code below generates a compile error (snipped) like:

numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No conversion from none to float64 for ‘$10return_value.1’, defined at None

File “main.py”, line 24:
def finalize(self):

if self.count:
return None
^

I’m sure I’m doing something obviously dumb, but would appreciate any insight into this issue!

from typing import Type
from numba import float64, int64
from numba.core.typing import Signature
from numba.experimental import jitclass

def sqlite_udaf(signature: Signature):
    def cls_wrapper(cls: Type):
        class_type = cls.class_type
        instance_type = class_type.instance_type
        finalize_func = instance_type.jit_methods['finalize']
        finalize_signature: Signature = signature.return_type(instance_type)
        finalize_func.compile(finalize_signature) # this is the line that fails
        return cls
    return cls_wrapper

@sqlite_udaf(float64(float64))
@jitclass(dict(count=int64))
class A:
    def __init__(self):
        self.count = 0

    def finalize(self):
        if self.count:
            return None
        return self.count
2

The error came from forcing the return type of finalize to float64. It should be returning an Optional(float64) instead.

1 Like
3

after further review, I solved this particular problem by wrapping the return value in the sqlite_udaf function like:

@sqlite_udaf(numba.optional(float64)(float64))

Thanks for the attention, I hope this helps someone in the future

4

I’m trying to use this jitclass as an aggregate sql function in sqlite. sqlite manages the memory, and hands us zeroed memory with sqlite3_aggregate_context.

How would I make the jitclass’s constructor ‘run’ on this memory, to initialize it correctly? Is there some generic paradigm for using a jitclass with non-owned memory?

5

To accept externally managed memory from C, the only supported way is via carray (see doc), which converts an external pointer into a NumPy array view.

6

Understood, and thanks. I know just enough to get myself in trouble :slightly_smiling_face:

That being said, I’ve had at least toy-program success with unsafe-casting to a jitclass, like
this

Is there a fatal flaw to that approach? Or is it just unsupported?

7

The unsafe_cast function is fine. The jitclass is designed to have the memory shareable but we have never connected all the API to make it easy.

8

Thanks much! I’ve learned a lot.

9

I don’t know if connecting it up to make it a part of numba is a hard thing or an easy thing, but being able to pass jitclass memory to C routines and back again seems (to me) to be a pretty nice thing. In this case, the C API allocates and owns the memory on behalf of the callback. Many C APIs take a void pointer to user-defined memory, then hand that memory back to a callback function.

Thanks again for the insight.