[Ironpython-users] numpy in IronPython

[Jeff Hardy]

On Tue, Jun 10, 2014 at 4:03 PM, Markus Schaber <m.schaber at codesys.com>
wrote:

> Hi, Jeff,
>
> Von: Jeff Hardy
> > On Tue, Jun 3, 2014 at 1:39 PM, Doug Blank <doug.blank at gmail.com> wrote:
> >> 2) A pure-Python version would be a lot of work (perhaps building on
> PyPy's RPython version and converting their C) and be slow, but would be
> little maintenance as most of the details for the current version of numpy
> would be static. Requires generic Python skills to develop (a large group
> of people have these skills; any generic Python implementation could use).
>
> > Anything that we can share with the PyPy/Jython teams will be a huge
> advantage. Having a pure-Python implementation would at least allow it to
> work, even if it wouldn't be fast (except on PyPy). It might also be a huge
> amount of work, but if it's shared between three smallish communities it
> might not be too bad.
>
> I think one of the problems is to avoid the boxing of doubles to objects
> when they're stored in arrays / vectors.
>

That's an improvement I would like to see in general. I think IP tries to
do that sometimes, but not in the general case. It should be possible for
range(10) to return a IList<int> and have it be transparently switched to a
IList<object> is something else is added. PyPy does something similar,
assuming lists (and dicts IIRC) are homogeneous until proven otherwise.

Or maybe it's a case of having the algorithms in Python and the data
structures in C#.


>
> > I just don't know enough about the architecture of numpy to say for sure
> - which parts are Python, which are Cython, and which are hand-written
> CPython modules. If they're going to depend on Cython, it's worth investing
> in a C# backend for that (unless we can generate cross-platform C++, but
> .NET Native might make that irrelevant anyway). It would also enable the
> wonderful Pandas library, hopefully. Getting an idea from the numpy team
> where they're headed would be a good idea before investing too much work in
> any case.
>
> As far as I can see, IronPython is JITted after being translated by the
> DLR. Maybe we could enhance that process to involve some type inference
> (similar to RPython) where possible, and to use Cython style type hints.
>
> With the appropriate type mappings (and possibly some hints), this could
> allow an "pure" Python version to get full .NET speed (e. G. by using .NET
> arrays of .NET double instead of python arrays).
>

That's what I'd prefer to see as well. It's more engineering work but I
think the payoff would be bigger in general. It also allows to start with a
slow-but-API-compatible Python version and increase performance later.

Still, I'm just providing my opinion - I don't have the time to work on
this directly, so the final decision will come down to whoever does the
actual work.

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