Runtime cast inside a @njit function?

0 views
Skip to first unread message

Alex Reisberg

unread,
Aug 3, 2017, 10:38:43 AM8/3/17
to Numba Public Discussion - Public
Hi all, I'm new to numba.  I have the following situation which I don't know how to resolve.

I have an event emitter that can emit events of various types. The list possible types are known at compile time, but when events are emitted, one would normally have to do some check and cast against a specific type in the list.  I also have a @generated_jit subscriber, which can handle all the types in that list.  The problem is that I want the event emitter to be @njit'ed as well, and I don't know how to do casting with numba.

If the question isn't clear, let me provide some pseudo-code


@njit
def emitter(subscriber):
  events
= ... # some priority queue containing elements of type TypeA, TypeB, TypeC, where TypeA, TypeB, TypeC are known in advanced.
 
for event in events:
    subscriber
(event) # numba will complain since it cannot type event.


@generated_jit(nopython=True)
def sub(event):
 
if event == TypeA:
   
return lambda event: ... # do something here
 elif: ...
 
...


Thanks!!!

Stanley Seibert

unread,
Aug 3, 2017, 10:43:31 AM8/3/17
to Numba Public Discussion - Public
There currently is not a way to do this in Numba because the compiler requires static typing of all variables given a particular set of input types.

However, we are planning mechanism that might help.  We are looking a few releases down the road at introducing an explicit "dynamic" type:


All manipulation of "dynamic" type values would happen in the Python interpreter (which could then call back into another nopython mode function).  This code would be slower than statically typed code, but it would allow an escape hatch to be able to call dynamically typed code without having to leave nopython mode, as you do now.


--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users+unsubscribe@continuum.io.
To post to this group, send email to numba...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/numba-users/db0c9692-954c-4a88-9f44-92f2ff471b7d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Alex Reisberg

unread,
Aug 3, 2017, 3:40:09 PM8/3/17
to Numba Public Discussion - Public
Thanks for the quick response!  This looks exciting!

It seems to me that the behavior of @generated_jit is already quite closely related to the dynamic behavior we want and maybe a small change would make it work (caveat emptor: I haven't yet looked very closely at the source code of numba).  Do you think the dynamic behavior could be done by subtyping?  Namely, arguments passed to a @generated_jit have to be subtypes of a concrete type.  Numba then just lets the @generated_jit function handle the type matching.

Side question: currently, where does the branching part of @generated_jit (i.e. the "if isinstance(..., ...)") happen? Interpreter or native?


On Thursday, August 3, 2017 at 9:43:31 AM UTC-5, Stanley Seibert wrote:
There currently is not a way to do this in Numba because the compiler requires static typing of all variables given a particular set of input types.

However, we are planning mechanism that might help.  We are looking a few releases down the road at introducing an explicit "dynamic" type:


All manipulation of "dynamic" type values would happen in the Python interpreter (which could then call back into another nopython mode function).  This code would be slower than statically typed code, but it would allow an escape hatch to be able to call dynamically typed code without having to leave nopython mode, as you do now.

On Thu, Aug 3, 2017 at 9:30 AM, Alex Reisberg <alex.f....@gmail.com> wrote:
Hi all, I'm new to numba.  I have the following situation which I don't know how to resolve.

I have an event emitter that can emit events of various types. The list possible types are known at compile time, but when events are emitted, one would normally have to do some check and cast against a specific type in the list.  I also have a @generated_jit subscriber, which can handle all the types in that list.  The problem is that I want the event emitter to be @njit'ed as well, and I don't know how to do casting with numba.

If the question isn't clear, let me provide some pseudo-code


@njit
def emitter(subscriber):
  events
= ... # some priority queue containing elements of type TypeA, TypeB, TypeC, where TypeA, TypeB, TypeC are known in advanced.
 
for event in events:
    subscriber
(event) # numba will complain since it cannot type event.


@generated_jit(nopython=True)
def sub(event):
 
if event == TypeA:
   
return lambda event: ... # do something here
 elif: ...
 
...


Thanks!!!

--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users...@continuum.io.

Alex Reisberg

unread,
Aug 3, 2017, 11:01:25 PM8/3/17
to Numba Public Discussion - Public
Since all my types are actually Records, is there a quick hack to make it work for now?

Alex Reisberg

unread,
Aug 4, 2017, 10:31:47 AM8/4/17
to Numba Public Discussion - Public
Alternatively, is it possible to get a pointer out of a record, then I can cast it later to a different record type, say, by carray or something like that?
Reply all
Reply to author
Forward
0 new messages