[Ironpython-users] numpy in IronPython

[Steve Baer]

We should also check with the Enthought guys to see what they did and if
they are willing to share.

-Steve


On Sun, Jun 1, 2014 at 6:29 AM, Doug Blank <doug.blank at gmail.com> wrote:

> 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/20140602/4f589165/attachment.html>