I agree that numpy support is a good first aim, I hope it'll open the
door to scipy support later.
To that end I've made my donation. As discussed with Fijal via a
private email I felt awkward with the new project (hence me asking the
question 60 emails back) as I'd offered a £600 donation which
Donation is in here too... numpy is just the beginning step in a great
direction. Go pypy!
On Sun, Oct 23, 2011 at 12:24 PM, Ian Ozsvald i...@ianozsvald.com wrote:
I agree that numpy support is a good first aim, I hope it'll open the
door to scipy support later.
To that end I've made my
Jacob Hall?n, 18.10.2011 18:41:
I'd just like to note that the compelling reason for PyPy to develop numpy
support is popular demand. We did a survey last spring, in which an
overwhelming number of people asked for numpy support. This indicates that
there is a large group of people who will
On 10/18/2011 02:41 PM Armin Rigo wrote:
Hi,
On Tue, Oct 18, 2011 at 14:19, Stefan Behnelstefan...@behnel.de wrote:
The other situation is where PyPy does its own thing and supports some NumPy
code that happens to run faster than in CPython, while other code does not
work at all, with the
On Wed, Oct 19, 2011 at 12:57 PM, Antonio Cuni anto.c...@gmail.com wrote:
On 19/10/11 13:42, Antonio Cuni wrote:
I'm not sure to interpret your sentence correctly.
Are you saying that you would still want a pypy+numpy+scipy,
even if it ran things slower than CPython? May I ask why?
ah
Hello Gary,
On 19/10/11 15:38, Gary Robinson wrote:
You would like pypy+numpy+scipy so that you could write fast
python-only algorithms and still use the existing libraries. I
suppose this is a perfectly reasonable usecase, and indeed
the current plan does not focus on this.
Yes. That is
You would like pypy+numpy+scipy so that you could write fast
python-only algorithms and still use the existing libraries. I
suppose this is a perfectly reasonable usecase, and indeed
the current plan does not focus on this.
Yes. That is exactly what I want.
However, I'd like to underline
I think the original topic of this discussion is numpy, not scipy.
The answer is that I don't know. I am sure that people will
reimplement whatever module is needed, or design a generic but slower
way to interface with C a la cpyext, or write a different C API, or
rely on Cython versions of
On Wed, Oct 19, 2011 at 10:38 -0400, Gary Robinson wrote:
By the way, did you ever considered the possibility of running pypy and
cpython side-by-side?
You do your pure-python computation on pypy, then you pipe them (e.g. by
using execnet) to a cpython process which does the processing
On Wed, Oct 19, 2011 at 6:47 PM, Leonardo Santagada santag...@gmail.com wrote:
Why not move more of scipy to cython/ctypes? That is what you guys
want for the future, and then it would not make anyone have to work on
something they have no interest in.
Independently of pypy's direction
On Mon, Oct 17, 2011 at 10:18 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Oct 17, 2011 at 8:40 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Mon, Oct 17, 2011 at 7:20 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord fuzzy...@gmail.com
On 17 October 2011 18:20, David Cournapeau courn...@gmail.com wrote:
[snip...]
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord fuzzy...@gmail.com wrote:
It seems odd to argue that extending numpy to pypy will be a net negative
for the community! Sure there are some difficulties involved, just
Hi,
On Tue, Oct 18, 2011 at 11:34, Dirkjan Ochtman dirk...@ochtman.nl wrote:
I'm confused -- I'm fairly convinced you think that a reasonable JIT
is harder than writing numpy, and not the other way around?
Let me chime in --- applying the JIT to numpypy or to any other
piece of RPython code
Michael Foord, 18.10.2011 11:44:
On 17 October 2011 18:20, David Cournapeau wrote:
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord wrote:
It seems odd to argue that extending numpy to pypy will be a net negative
for the community! Sure there are some difficulties involved, just as
there
are
Hi,
On Tue, Oct 18, 2011 at 14:19, Stefan Behnel stefan...@behnel.de wrote:
The other situation is where PyPy does its own thing and supports some NumPy
code that happens to run faster than in CPython, while other code does not
work at all, with the possibility to replace it in a PyPy specific
As an example - I want numpy for client work. For my clients (the main
being a physics company that is replacing Fortran with Python) numpy
is at the heart of their simulations. However - numpy is used with
matplotlib and pyCUDA and parts of scipy. If basic tools like FFT
aren't available
On Mon, Oct 17, 2011 at 9:31 AM, Massa, Harald Armin c...@ghum.de wrote:
The main thing is that we want to provide something immediately
useful. That is a numpy which maybe does not integrate (yet) with the
entire ecosystem, but is much faster on both array computations and
pure python
David Cournapeau, 17.10.2011 00:01:
On Sun, Oct 16, 2011 at 10:20 PM, Ian Ozsvald wrote:
how big is the scipy ecosystem beyond numpy? What's the rough line
count for Python, C, Fortran etc that depends on numpy?
The ecosystem is pretty big. There are at least in the order of
hundred of
The ecosystem is pretty big. There are at least in the order of
hundred of packages that depend directly on numpy and scipy.
For scipy alone, the raw count is around 150k-300k LOC (it is a bit
hard to estimate because we include some swig-generated code that I
have ignored here, and some
This would be very useful since
you don't need to use Cython or any other things like this to provide
working code and it already caters for some group of people.
Hi Fijal. This would be useful for a demo - but will it be useful for
the userbase that becomes motivated to integrate Cython and
On Mon, Oct 17, 2011 at 8:29 AM, Ian Ozsvald i...@ianozsvald.com wrote:
This would be very useful since
you don't need to use Cython or any other things like this to provide
working code and it already caters for some group of people.
Hi Fijal. This would be useful for a demo - but will
On 17 October 2011 13:35, Alex Gaynor alex.gay...@gmail.com wrote:
On Mon, Oct 17, 2011 at 8:29 AM, Ian Ozsvald i...@ianozsvald.com wrote:
This would be very useful since
you don't need to use Cython or any other things like this to provide
working code and it already caters for some
Let me ask the opposite question: What route do you envision that gives us
both the speed we (and everyone else) desires, while not having any of these
issues? That's not a question that has a very good answer I think.
Hi Alex. I don't have a proposed route. I'm (sadly) too ignorant, I'm
On 17 October 2011 16:42, Ian Ozsvald i...@ianozsvald.com wrote:
For pypy I can't see any better approach than the way they have taken.
Once
people are using numpy on pypy the limitations and missing parts will
become
clear, and not only will the way forward be more obvious but there will
On Mon, Oct 17, 2011 at 6:01 PM, Stefan Behnel stefan...@behnel.de wrote:
Maciej Fijalkowski, 17.10.2011 17:46:
- pypy's numpy *will* integrate in some sort of way with existing
C/fortran libraries, but this way *will* be different than current
CPython C API. It's really just too hard to get
On Mon, Oct 17, 2011 at 12:01 PM, Stefan Behnel stefan...@behnel.de wrote:
Maciej Fijalkowski, 17.10.2011 17:46:
- pypy's numpy *will* integrate in some sort of way with existing
C/fortran libraries, but this way *will* be different than current
CPython C API. It's really just too hard to
On Mon, Oct 17, 2011 at 1:20 PM, David Cournapeau courn...@gmail.comwrote:
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord fuzzy...@gmail.com wrote:
Travis' post seems to suggest that it is the responsibility of the *pypy*
dev team to do the work necessary to integrate the numpy refactor
On Mon, Oct 17, 2011 at 6:22 PM, Alex Gaynor alex.gay...@gmail.com wrote:
Why can't you have scipy and friends without a C-API? Presumabley it's all
code that either manipulates an array or calls into an existing lib to
manipulate an array. Why can't you write pure python code to manipulate
On Mon, Oct 17, 2011 at 7:20 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord fuzzy...@gmail.com wrote:
Travis' post seems to suggest that it is the responsibility of the *pypy*
dev team to do the work necessary to integrate the numpy refactor
Alex Gaynor, 17.10.2011 18:14:
On Mon, Oct 17, 2011 at 12:01 PM, Stefan Behnel wrote:
Maciej Fijalkowski, 17.10.2011 17:46:
- pypy's numpy *will* integrate in some sort of way with existing
C/fortran libraries, but this way *will* be different than current
CPython C API. It's really just too
On Mon, Oct 17, 2011 at 8:40 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Mon, Oct 17, 2011 at 7:20 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord fuzzy...@gmail.com wrote:
Travis' post seems to suggest that it is the responsibility of the
31 matches
Mail list logo
