Problem with Numba

[Doug Jenkins]

In some of my earlier work using Pyxll I got a huge performance improvement with use of the Numba jit compiler on selected routines, particularly those that operated on a large array, where there were no Numpy or Scipy functions to do the job.

If I try to import Numba when using ver 2.02 (from numba import double, jit, autojit) I get:

ImportError: cannot import name testing
from . import testing, decorators
File "C:\Users\Doug\Documents\Anaconda\lib\site-packages\numba_init__.py", line 5, in <module>
from numba import double, jit, autojit
File "c:\Users\Doug\Documents\SPREAD\ExcelPython2\Test1.py", line 23, in <module>
File "<string>", line 1, in <module>
exec "import " + module in vars
File "c:\Users\Doug\Documents\SPREAD\ExcelPython2\xlpython\xlpyserver.py", line 86, in Module
return func(*args)
File "C:\Users\Doug\Documents\Anaconda\lib\site-packages\win32com\server\policy.py", line 585, in _invokeex
return S_OK, -1, self.invokeex(dispid, lcid, wFlags, args, None, None)
File "C:\Users\Doug\Documents\Anaconda\lib\site-packages\win32com\server\policy.py", line 282, in invoke
return self.invoke(dispid, lcid, wFlags, args)
File "C:\Users\Doug\Documents\Anaconda\lib\site-packages\win32com\server\policy.py", line 277, in Invoke

Any suggestions?

A couple of other points:

I added the numba folder to the Windows path. Before that I got a different error message (but I didn't save it).

I'm not certain, but I think with ExcelPython Ver 1 I had the import statement left in some of my modules, but I commented out all the calls to numba, because they didn't work.

[Doug Jenkins]

Following up on the previous post; I have put Numba on hold for now, and I'm experimenting with F2py, to compile Fortran code in Python readable form. There's quite a bit more work involved doing that of course, but once it was set up properly it was surprisingly easy. Seems to work with Excel-Python with no problems.

[Eric Reynolds]

Nice to know something works with no problems!

From the discussion forums one gets the impression nothing ever works... but it's probably just adverse selection! (i.e. I only get to hear about it when it doesn't work)

I am going to take a look at that numba issue soon.

[Eric Reynolds]

Hi Doug,

I have just installed Anaconda, and I am having no trouble at all mixing numba with ExcelPython. For example:

# Book1.py
from xlpython import *

from numba import double, jit, autojit

from numba import jit
from numpy import arange

# jit decorator tells Numba to compile this function.
# The argument types will be inferred by Numba when function is called.
@jit
def sum2d(arr):
    M, N = arr.shape
    result = 0.0
    for i in range(M):
        for j in range(N):
            result += arr[i,j]
    return result

@xlfunc
@xlarg("a", "nparray")
def udf_sum2d(a):
    return sum2d(a)

From VBA I can do:

Function numba_test()
    Set numpy = Py.Module("scipy")
    Set book1py = Py.Module("Book1", True) ' True so it auto-reloads
    Set arr = Py.Call(numpy, "randn", Py.Tuple(2, 3))
    numba_test = Py.Var(Py.Call(book1py, "sum2d", Py.Tuple(arr)))
End Function

?numba_test()
 2.69950011122053

and also using the add-in I am having no trouble using udf_sum2d from a worksheet formula.

So I suspect it's a problem with your local setup. Does from numba import double, jit, autojit work OK from your interactive python interpreter? If it works there, it should work in ExcelPython too.

Eric.

[Doug Jenkins]

Thanks for checking Eric, I should have thought to try it direct from Python myself.

It seems that the error message I was getting was due to a new version of Numba, which I installed at about the same time as ExcelPython2. When I re-install the previous version I can successfully import numba, and run a simple function.

I'm still having problems with it with more complex stuff, but I get exactly the same error messages running from Excel or direct from Python, so it's nothing to do with Excel Python.

[Eric Reynolds]

Yes, that is the nice thing about v2 compared with v1, that internally it is exactly like running Python from the command line so the behaviour should be exactly the same. This was not the case with v1 where the Python runtime was loaded as a DLL, which meant there could be subtle differences in the way libraries were loaded.