On Mon, Jun 2, 2014 at 1:13 PM, Steve Baer <st...@mcneel.com> wrote: > We should also check with the Enthought guys to see what they did and if > they are willing to share. >
That is the code here that I mentioned in the first post: https://www.enthought.com/repo/.iron/ I can't tell what license this is done under. Also, it is Windows only. It looks like a Cython for IronPython might be closer to working: https://bitbucket.org/cwitty/cython-for-ironpython/overview Especially here considering these: https://bitbucket.org/cwitty/cython-for-ironpython/src/9dc7e1a2d56a/Cython/Includes/posix/?at=default https://bitbucket.org/cwitty/cython-for-ironpython/commits/9dc7e1a2d56a3e3c8a7b3c7a5d23073a54b2b814 But, I haven't worked much with Python and C libraries. -Doug > > -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