Hello David,
thank you.
I followed your suggestion but I was unable to make it work.
I surprisingly found that with numpy in a different folder, it worked.
I am afraid it is due to the fact that the first one is not a linux filesystem
and cannot deal with permission and ownership.
This would make
On Fri, Sep 25, 2009 at 6:50 PM, Citi, Luca wrote:
> Thanks for your reply.
> So, what is the correct way to test a numpy development version without
> installing it in /usr/lib/... or /usr/local/lib/.. ?
> What do you guys do?
Build in place, but test from outside the source tree. I for example
Thanks for your reply.
So, what is the correct way to test a numpy development version without
installing it in /usr/lib/... or /usr/local/lib/.. ?
What do you guys do?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
On Fri, Sep 25, 2009 at 9:50 AM, Citi, Luca wrote:
> I am sorry.
> I followed your suggestion.
> I re-checked out the svn folder and then compiled with
> $ python setup.py build_src --inplace build_ext --inplace
> but I get the same behaviour.
> If I am inside I get the NameError, if I am outside
I am sorry.
I followed your suggestion.
I re-checked out the svn folder and then compiled with
$ python setup.py build_src --inplace build_ext --inplace
but I get the same behaviour.
If I am inside I get the NameError, if I am outside and use path.insert, it
successfully performs zero tests.
I ha
Thank you both for your help!
$ python setup.py build_src --inplace build_ext --inplace
I'll give it a try.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thank you for your instantaneuos reply!
This is what I usually do:
from the numpy folder I run (emptying the build folder if I just fetched svn
updates)
$ python setup build.py
$ cd build/lib-...
$ ipython
In [1]: import numpy as np
In [2]: np.__version__
Out[2]: '1.4.0.dev7417'
Everything works
On Thu, Sep 24, 2009 at 16:43, Citi, Luca wrote:
> What is the correct way of running the tests (without installing the
> development version in the system)?
Build inplace:
$ python setup.py build_src --inplace build_ext --inplace
--
Robert Kern
"I have come to believe that the whole worl
On Thu, Sep 24, 2009 at 3:43 PM, Citi, Luca wrote:
> Hello
> I noticed that python's "any" can be faster than numpy's "any" (and the
> similarly for "all").
> Then I wondered why.
> I realized that numpy implements "any" as logical_or.reduce (and "all" as
> logical_and.reduce).
> This means that
Hello
I noticed that python's "any" can be faster than numpy's "any" (and the
similarly for "all").
Then I wondered why.
I realized that numpy implements "any" as logical_or.reduce (and "all" as
logical_and.reduce).
This means that numpy cannot take advantage of short-circuiting.
Looking at the t
10 matches
Mail list logo
