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.bl...@gmail.com> wrote: > On Sun, Jun 1, 2014 at 3:05 AM, Jeff Hardy <jdha...@gmail.com> wrote: > >> On Sat, May 31, 2014 at 3:23 PM, Doug Blank <doug.bl...@gmail.com> wrote: >> >>> On Fri, May 30, 2014 at 5:22 PM, Steve Baer <st...@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 >> > >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
