[Ironpython-users] numpy in IronPython

Doug Blank doug.blank at gmail.com
Sun Jun 1 15:29:07 CEST 2014


On Sun, Jun 1, 2014 at 3:05 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Sat, May 31, 2014 at 3:23 PM, Doug Blank <doug.blank at gmail.com> wrote:
>
>> On Fri, May 30, 2014 at 5:22 PM, Steve Baer <steve at mcneel.com> wrote:
>>
>>> I would definitely be interested in helping, but don't exactly know
>>> where to start. We have a lot of users who would love to get access to
>>> numpy on our OSX and 64bit windows versions of our product.  This is only
>>> going to become a bigger problem in the future since we will probably only
>>> have a 64bit version for Window in the next version of Rhino.
>>>
>>
>> I agree. Let's start a serious discussion about how to solve the lack of
>> numpy in IronPython.
>>
>> We could look into using ctypes (IronClad?) and wrap what already exists.
>>
>> We could look into a cross-platform DLL drop-in replacement.
>>
>> Between speed and compatibility, initially I'm most interested in
>> compatibility. But speed should be a long term goal.
>>
>> We could write a pure-python prototype initially, and slowly move that to
>> C#, or another CLR language. That would be useful for all non-C-based
>> Python implementations, and would probably be quickest to write and test.
>>
>> A related note: Python3 just added a new matrix multiplication operator
>> [1]. Hope to see more numpy-related functionality in standard Python in the
>> future.
>>
>> Other ideas? Where to start?
>>
>
> I would start by asking the NumPy team what the best option is, and seeing
> what the NumPyPy team are doing - the more work that can be shared, the
> better.
>

That is a good idea, and I started to try to define what we might mean by
"best option." Almost all of the work I have seen coming from most related
projects would define best in terms of speed. However, this comes at a
pretty big cost in terms of maintenance---for example, having wrapped C
libraries compiled for each platform, for each bus size (32, 64).

In poking around, I think the Jython needs might be closest to ours. Looks
like they have two starts: a pure-Java library based on the older Numeric
[1], and a native interface for talking directly to C [2]. The native
interface is a long term project, and is not yet to the point of working
with numpy. As a quick test, I tried to IKVM-convert the pure Java jar file
into a DLL. I think that could work (eventually) but would require bringing
a lot of Jython, and would probably always be a little wonky. In addition,
that API is the older Numeric.

A third option, as mentioned by Ivan, is to have a bridge to CPython
interfacing with numpy. But that would make CPython a dependency---not
really something that many IronPython users would appreciate.

Of course, if one is looking for doing numeric operations, you could use a
different .NET/Mono math library. But what I am interested in is the numpy
API, so that other code will be usable in IronPython.

To me, it looks like the best bet at this point in time is to write our
own. The next question is: write it in pure Python, or C#/F#/etc.

If we write it in pure Python, there is the chance that some Jython
developers (and maybe other Python implementation people) might be
interested in helping. It would be slow, but we could rely on Python for
handling type operations (float times int) to do the right thing. It would
also be immediately usable by future CPython users. It could be the case
that a future Python implementation could do some JITting to make it run
fast enough. (A pure Python version might also be useful for educational
uses, as I presume it would be more easily understood by Python students).

If we write it as a CLR library, it would be as fast as managed code would
allow, and be available for other CLR languages (like F#, Boo, etc). But we
would probably be alone in developing it, as it is mostly of interest to
Python users using numpy and the CLR.

I guess I am leaning towards a pure Python implementation of the latest
numpy API. Perhaps followed up by a DLL version.

-Doug

[1] - https://bitbucket.org/zornslemon/jnumeric-ra/overview
[2] - http://jyni.org/



>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140601/47ded543/attachment.html>


More information about the Ironpython-users mailing list