On 15/02/15 10:49, Armin Rigo wrote:
Hi Matti,
On 14 February 2015 at 17:44, Matti Picus wrote:
That makes sense, thanks. I will see if I can easily reuse the c code as a
shared object rather than a module, and what effect that has on timing.
Hi Matti,
On 14 February 2015 at 17:44, Matti Picus wrote:
> That makes sense, thanks. I will see if I can easily reuse the c code as a
> shared object rather than a module, and what effect that has on timing.
Note that it's what ffi.verify() is for: you add any amount of custom
C code there.
On 14/02/15 11:40, Armin Rigo wrote:
Hi Matti,
On 13 February 2015 at 14:46, Matti Picus wrote:
I am close to releasing a blog post about numpy.linalg
A comment: saying "In order to test it out, download PyPy 2.5.0 or
later, and install the pypy version of numpy" in the conclusion is, in
my
Hi Matti,
On 13 February 2015 at 14:46, Matti Picus wrote:
> I am close to releasing a blog post about numpy.linalg
A comment: saying "In order to test it out, download PyPy 2.5.0 or
later, and install the pypy version of numpy" in the conclusion is, in
my opinion, both too late and not precise
Very interesting.
If that really working it will be game changer.
Can it build Scipy, scikit-learn, matplotlib now?
Pandas already working i think.
On Fri, Feb 13, 2015 at 8:16 PM, Matti Picus wrote:
> I am close to releasing a blog post about numpy.linalg
>
> https://gist.github.com/mattip/25680
I am close to releasing a blog post about numpy.linalg
https://gist.github.com/mattip/25680e68fe7e2856fe0c
Note the benchmark section, this is not a typo. Here's how I got to the
conclusion that cpyext is faster than python+cffi.
I installed numpy from the pypy/numpy repo on a nightly after 2
