Re: [Numpy-discussion] slow import of numpy modules

On Thu, 2008-07-03 at 01:25 -0500, Robert Kern wrote: > > Before: > $ time python -c "import numpy" > python -c "import numpy" 0.30s user 0.82s system 91% cpu 1.232 total > > Removal of finfo: > $ time python -c "import numpy" > python -c "import numpy" 0.27s user 0.82s system 94% cpu 1.156 to

Re: [Numpy-discussion] slow import of numpy modules

On Wed, Jul 2, 2008 at 23:56, David Cournapeau <[EMAIL PROTECTED]> wrote: > On Wed, 2008-07-02 at 23:36 -0500, Robert Kern wrote: >> >> Neither one has participated in this thread. At least, no such email >> has made it to my inbox. > > This was in the thread "import numpy" is slow, I mixed the two

Re: [Numpy-discussion] FFT's & IFFT's on images

On Wed, Jul 2, 2008 at 3:53 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 3:33 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: >> Mike Sarahan wrote: >>> I agree that the components are very small, and in a numeric sense, I >>> wouldn't worry at all about them, but the image re

Re: [Numpy-discussion] slow import of numpy modules

On Thu, 2008-07-03 at 13:56 +0900, David Cournapeau wrote: > > Ok, will do it, then. I put the patches in ticket 838. I tried to commit the changes directly, but it looks like they disabled some proxy settings necessary to commit to svn at my company. On my computer, the changes cut 1/3 of total

Re: [Numpy-discussion] slow import of numpy modules

On Wed, 2008-07-02 at 23:36 -0500, Robert Kern wrote: > > Neither one has participated in this thread. At least, no such email > has made it to my inbox. This was in the thread "import numpy" is slow, I mixed the two, sorry. > > I think it's worth moving these imports into the functions, then.

Re: [Numpy-discussion] slow import of numpy modules

On Wed, Jul 2, 2008 at 23:14, David Cournapeau <[EMAIL PROTECTED]> wrote: > On Wed, 2008-07-02 at 21:50 -0500, Robert Kern wrote: >> >> So ... what were you referring to? > > To a former email from Matthieu in this thread (or Stefan ?). Neither one has participated in this thread. At least, no suc

Re: [Numpy-discussion] slow import of numpy modules

On Wed, 2008-07-02 at 21:50 -0500, Robert Kern wrote: > > So ... what were you referring to? To a former email from Matthieu in this thread (or Stefan ?). > > There is special purpose code, yes. We used to use it to load proxy > objects for scipy subpackages such that "import scipy" would have

Re: [Numpy-discussion] slow import of numpy modules

On Wed, Jul 2, 2008 at 21:38, David Cournapeau <[EMAIL PROTECTED]> wrote: > On Wed, 2008-07-02 at 21:21 -0500, Robert Kern wrote: >> On Wed, Jul 2, 2008 at 20:23, David Cournapeau >> <[EMAIL PROTECTED]> wrote: >> >> > I think that import numpy.core being slower than import numpy is a bug >> > which

Re: [Numpy-discussion] slow import of numpy modules

On Wed, 2008-07-02 at 21:21 -0500, Robert Kern wrote: > On Wed, Jul 2, 2008 at 20:23, David Cournapeau > <[EMAIL PROTECTED]> wrote: > > > I think that import numpy.core being slower than import numpy is a bug > > which can be solved without breaking anything, though. > > It does not appear to be

Re: [Numpy-discussion] slow import of numpy modules

On Wed, Jul 2, 2008 at 20:23, David Cournapeau <[EMAIL PROTECTED]> wrote: > I think that import numpy.core being slower than import numpy is a bug > which can be solved without breaking anything, though. It does not appear to be slower to me. -- Robert Kern "I have come to believe that the who

Re: [Numpy-discussion] slow import of numpy modules

On Wed, 2008-07-02 at 17:00 -0700, Michael McNeil Forbes wrote: > > One could use an environmental variable such as > NUMPY_SUPPRESS_TOP_LEVEL_IMPORTS, that, if defined, suppresses the > importing of unneeded packages. This would only affect systems that > define this variable, thus not bre

Re: [Numpy-discussion] slow import of numpy modules

On 2 Jul 2008, at 3:59 PM, Robert Kern wrote: > On Wed, Jul 2, 2008 at 17:43, Nathan Jensen > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I was wondering if there was any way to speed up the global import of >> numpy modules. For a simple import numpy, it takes ~250 ms. In >> comparison, importing

Re: [Numpy-discussion] FFT's & IFFT's on images

Beautiful! Thanks Stefan! It was the PIL bug. Thanks for all the replies. -Mike On Thu, 2008-07-03 at 01:00 +0200, Stéfan van der Walt wrote: > Hi Mike > > 2008/7/3 Mike Sarahan <[EMAIL PROTECTED]>: > > I agree that the components are very small, and in a numeric sense, I > > wouldn't worry at

Re: [Numpy-discussion] FFT's & IFFT's on images

Hi Mike 2008/7/3 Mike Sarahan <[EMAIL PROTECTED]>: > I agree that the components are very small, and in a numeric sense, I > wouldn't worry at all about them, but the image result is simply noise, > albeit periodic-looking noise. > > Here's a code snippet: > ---

Re: [Numpy-discussion] slow import of numpy modules

On Wed, Jul 2, 2008 at 17:43, Nathan Jensen <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering if there was any way to speed up the global import of > numpy modules. For a simple import numpy, it takes ~250 ms. In > comparison, importing Numeric is only taking 40 ms. It appears that > even if

Re: [Numpy-discussion] FFT's & IFFT's on images

On Wed, Jul 2, 2008 at 3:33 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Mike Sarahan wrote: >> I agree that the components are very small, and in a numeric sense, I >> wouldn't worry at all about them, but the image result is simply noise, >> albeit periodic-looking noise. > > Fernando Perez and

Re: [Numpy-discussion] FFT's & IFFT's on images

On Wed, Jul 2, 2008 at 17:14, Mike Sarahan <[EMAIL PROTECTED]> wrote: > I agree that the components are very small, and in a numeric sense, I > wouldn't worry at all about them, but the image result is simply noise, > albeit periodic-looking noise. > > Here's a code snippet: > -

[Numpy-discussion] slow import of numpy modules

Hi, I was wondering if there was any way to speed up the global import of numpy modules. For a simple import numpy, it takes ~250 ms. In comparison, importing Numeric is only taking 40 ms. It appears that even if you only import a numpy submodule, it loads all the libraries, resulting in the pa

Re: [Numpy-discussion] FFT's & IFFT's on images

Mike Sarahan wrote: > I agree that the components are very small, and in a numeric sense, I > wouldn't worry at all about them, but the image result is simply noise, > albeit periodic-looking noise. Fernando Perez and John Hunter have written a nice FFT image denoising example: http://matplotlib.s

Re: [Numpy-discussion] FFT's & IFFT's on images

I agree that the components are very small, and in a numeric sense, I wouldn't worry at all about them, but the image result is simply noise, albeit periodic-looking noise. Here's a code snippet: import numpy,Image img=Image.open('LlamaTeeth.jpg') arr=nump

Re: [Numpy-discussion] Doctest items

On Wed, Jul 2, 2008 at 5:47 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > How about a slight modification to Fernando's idea: a dummy function that > > a) Does nothing if matplotlib is not installed > b) Otherwise passes through calls to matplotlib, after setting the > backend to /dev/null.

Re: [Numpy-discussion] Ctypes required? Fails to build.

On Wed, Jul 2, 2008 at 16:43, James Turner <[EMAIL PROTECTED]> wrote: > Hello, > > I'm trying to build Python 2.5.1 on Solaris 9 with the Sun > WorkShop 6 compiler, but it is failing to build the ctypes > extension. Can anyone tell me whether NumPy 1.1 (or 1.04) can > work without ctypes, please?

Re: [Numpy-discussion] Ctypes required? Fails to build.

Hi James 2008/7/2 James Turner <[EMAIL PROTECTED]>: > I'm trying to build Python 2.5.1 on Solaris 9 with the Sun > WorkShop 6 compiler, but it is failing to build the ctypes > extension. Can anyone tell me whether NumPy 1.1 (or 1.04) can > work without ctypes, please? What about SciPy 0.6? Maybe >

Re: [Numpy-discussion] FFT's & IFFT's on images

On Wed, Jul 2, 2008 at 16:33, Mike Sarahan <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to do phase reconstruction on images which involves switching > back and forth between Fourier space and real space. I'm trying to test > numpy (& scipy, for that matter) just to see if I can go back and for

Re: [Numpy-discussion] New numpy.test() failures

On Wednesday 02 July 2008 15:26:05 you wrote: > On Wednesday 02 July 2008 15:13:37 Nils Wagner wrote: > > I can reproduce the test failures on my old 32-bit laptop. > > As you should. My bad, I messed up on my last commit. I'll fix that later > this afternoon. OK, so it should be fixed in v5332. S

Re: [Numpy-discussion] FFT's & IFFT's on images

Hi Mike 2008/7/2 Mike Sarahan <[EMAIL PROTECTED]>: > I'm trying to do phase reconstruction on images which involves switching > back and forth between Fourier space and real space. I'm trying to test > numpy (& scipy, for that matter) just to see if I can go back and forth. > After an FFT/iFFT, t

Re: [Numpy-discussion] New numpy.test() failures

On Wed, Jul 2, 2008 at 5:22 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > The Mac seems to have a whole different set of errors than the other bots, > lots of import errors like > > ERROR: Failure: ImportError (cannot import name log) > > I wonder if there is a path issue somewhere? At least o

Re: [Numpy-discussion] Doctest items

2008/7/2 Ryan May <[EMAIL PROTECTED]>: >> To be clear, these aren't tests of the numpy code. The tests would be >> to make sure the examples still run. >> > Right. I just don't think effort should be put into making examples > using matplotlib run as doctests. If the behavior is important, numpy

[Numpy-discussion] Ctypes required? Fails to build.

Hello, I'm trying to build Python 2.5.1 on Solaris 9 with the Sun WorkShop 6 compiler, but it is failing to build the ctypes extension. Can anyone tell me whether NumPy 1.1 (or 1.04) can work without ctypes, please? What about SciPy 0.6? Maybe that's a silly question, but I can't see how to make i

[Numpy-discussion] FFT's & IFFT's on images

Hi, I'm trying to do phase reconstruction on images which involves switching back and forth between Fourier space and real space. I'm trying to test numpy (& scipy, for that matter) just to see if I can go back and forth. After an FFT/iFFT, the resulting image is garbage. I'm using numpy.fft.fft

Re: [Numpy-discussion] New numpy.test() failures

very likely a path issue. i've had two hard drive crashed on the buildslave box this week. i'm sure something's fubar'd. i'll take a look. thanks for the heads up. On Wed, Jul 2, 2008 at 2:22 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On Wed, Jul 2, 2008 at 2:45 PM, Barry Wark <[EMAIL P

Re: [Numpy-discussion] New numpy.test() failures

On Wed, Jul 2, 2008 at 2:45 PM, Barry Wark <[EMAIL PROTECTED]> wrote: > Fixed. Sorry. The Mac seems to have a whole different set of errors than the other bots, lots of import errors like ERROR: Failure: ImportError (cannot import name log) I wonder if there is a path issue somewhere? Chuck _

Re: [Numpy-discussion] Should we fix Ticket #709?

2008/7/2 Zbyszek Szmek <[EMAIL PROTECTED]>: >> That's Ticket #709 : >> >> > I'm faily sure that: >> > numpy.isnan(datetime.datetime.now() >> > ...should just return False and not raise an exception. > IMHO numpy.isnan() makes no sense for non-numeri

Re: [Numpy-discussion] New numpy.test() failures

Fixed. Sorry. On Wed, Jul 2, 2008 at 1:07 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: > The buildbot test command should be using sys.exit to return the > success flag from the test run, but it's not. The FreeBSD's test > command is: > > /usr/local/bin/python2.4 -c 'import numpy,sys;sys.exit(not

Re: [Numpy-discussion] set_local_path in test files

2008/7/2 Robert Kern <[EMAIL PROTECTED]>: > On Wed, Jul 2, 2008 at 14:34, Alan McIntyre <[EMAIL PROTECTED]> wrote: >> On Wed, Jul 2, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote: >>> Please remove them and adjust the imports. As I've mentioned before, >>> numpy and scipy can now reliably

Re: [Numpy-discussion] New numpy.test() failures

The buildbot test command should be using sys.exit to return the success flag from the test run, but it's not. The FreeBSD's test command is: /usr/local/bin/python2.4 -c 'import numpy,sys;sys.exit(not numpy.test(level=,verbosity=).wasSuccessful())' while the OSX bot's command is python

Re: [Numpy-discussion] New numpy.test() failures

On Wed, Jul 2, 2008 at 1:26 PM, Pierre GM <[EMAIL PROTECTED]> wrote: > On Wednesday 02 July 2008 15:13:37 Nils Wagner wrote: > > I can reproduce the test failures on my old 32-bit laptop. > > As you should. My bad, I messed up on my last commit. I'll fix that later > this > afternoon. > ___ > Hmm

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 14:34, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote: >> Please remove them and adjust the imports. As I've mentioned before, >> numpy and scipy can now reliably be built in-place with "python >> setup.py buil

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > Please remove them and adjust the imports. As I've mentioned before, > numpy and scipy can now reliably be built in-place with "python > setup.py build_src --inplace build_ext --inplace". This is a more > robust method to test

Re: [Numpy-discussion] New numpy.test() failures

On Wednesday 02 July 2008 15:13:37 Nils Wagner wrote: > I can reproduce the test failures on my old 32-bit laptop. As you should. My bad, I messed up on my last commit. I'll fix that later this afternoon. ___ Numpy-discussion mailing list Numpy-discussi

Re: [Numpy-discussion] New numpy.test() failures

On Wed, 02 Jul 2008 19:41:56 +0200 "Nils Wagner" <[EMAIL PROTECTED]> wrote: >> >> This shows up on all the 64-bit buildbots also. But the >>32 bit Mac still >> works. >> >> Chuck I can reproduce the test failures on my old 32-bit laptop. Linux linux 2.6.11.4-21.17-default #1 Fri Apr 6 08:4

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 13:58, Pearu Peterson <[EMAIL PROTECTED]> wrote: > On Wed, July 2, 2008 8:25 pm, Robert Kern wrote: >> On Wed, Jul 2, 2008 at 09:01, Alan McIntyre <[EMAIL PROTECTED]> >> wrote: >>> On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson <[EMAIL PROTECTED]> >>> wrote: Alan McIntyr

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 12:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > Please remove them and adjust the imports. As I've mentioned before, > numpy and scipy can now reliably be built in-place with "python > setup.py build_src --inplace build_ext --inplace". This is a more > robust method to tes

Re: [Numpy-discussion] set_local_path in test files

On Wed, July 2, 2008 8:25 pm, Robert Kern wrote: > On Wed, Jul 2, 2008 at 09:01, Alan McIntyre <[EMAIL PROTECTED]> > wrote: >> On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson <[EMAIL PROTECTED]> >> wrote: >>> Alan McIntyre wrote: Some test files have a set_local_path()/restore_path() pair at th

Re: [Numpy-discussion] Change of behavior in flatten between 1.0.4 and 1.1

On Tue, 1 Jul 2008, Pauli Virtanen wrote: > Tue, 01 Jul 2008 17:18:55 -0400, Stuart Brorson wrote: >> I have noticed a change in the behavior of numpy.flatten(True) between >> NumPy 1.0.4 and NumPy 1.1. The change affects 3D arrays. I am >> wondering if this is a bug or a feature. [...] > To

Re: [Numpy-discussion] New numpy.test() failures

> > This shows up on all the 64-bit buildbots also. But the >32 bit Mac still > works. > > Chuck There are also new test failures in scipy == FAIL: Tests the confidence intervals of the trimmed mean. --

Re: [Numpy-discussion] Time to fix ticket #390?

On Wed, Jul 2, 2008 at 05:29, Zbyszek Szmek <[EMAIL PROTECTED]> wrote: > On Sat, Jun 28, 2008 at 04:31:22PM -0600, Charles R Harris wrote: >> Questions about ticket >> #390: > > Unfortunately, Trac has a problem, it's impossible to view the ticket:

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 09:01, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson <[EMAIL PROTECTED]> wrote: >> Alan McIntyre wrote: >>> Some test files have a set_local_path()/restore_path() pair at the >>> top, and some don't. Is there any reason to be chang

Re: [Numpy-discussion] New numpy.test() failures

On Wed, Jul 2, 2008 at 10:56 AM, Nils Wagner <[EMAIL PROTECTED]> wrote: > Hi all, > > If I run numpy.test() > > >>> numpy.__version__ > '1.2.0.dev5331' > > I obtain > This shows up on all the 64-bit buildbots also. But the 32 bit Mac still works. Chuck ___

[Numpy-discussion] New numpy.test() failures

Hi all, If I run numpy.test() >>> numpy.__version__ '1.2.0.dev5331' I obtain == FAIL: Tests count -- Traceback (most recent call last): File "/usr/local/li

Re: [Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1

On Wed, Jul 2, 2008 at 9:58 AM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On Wed, Jul 2, 2008 at 7:12 AM, Francesc Alted <[EMAIL PROTECTED]> > wrote: > >> Hi, >> >> I've seen that NumPy has changed the representation of complex numbers >> starting with NumPy 1.1. Before, it was: >> >> >>>

Re: [Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1

On Wed, Jul 2, 2008 at 7:12 AM, Francesc Alted <[EMAIL PROTECTED]> wrote: > Hi, > > I've seen that NumPy has changed the representation of complex numbers > starting with NumPy 1.1. Before, it was: > > >>> numpy.__version__ > '1.0.3' > >>> repr(numpy.complex(0))# The Python type > '0j' > >>>

Re: [Numpy-discussion] set_local_path in test files

Hi, >> The idea behind set_local_path is that it allows running tests >> inside subpackages without the need to rebuild the entire package. > > Ah, thanks; I'd forgotten about that. I'll leave them alone, then. I > made a note for myself to make sure it's possible to run tests locally > without

[Numpy-discussion] Enthought Python Distribution

Greetings, We're pleased to announce the beta release of the Enthought Python Distribution for *Mac OS X*. http://www.enthought.com/products/epd.php This release should safely install alongside other existing Python installations on your Mac. With the Mac OS X platform support, EPD now pr

Re: [Numpy-discussion] set_local_path in test files

On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson <[EMAIL PROTECTED]> wrote: > Alan McIntyre wrote: >> Some test files have a set_local_path()/restore_path() pair at the >> top, and some don't. Is there any reason to be changing sys.path like >> this in the test modules? If not, I'll take them out w

Re: [Numpy-discussion] set_local_path in test files

Alan McIntyre wrote: > Some test files have a set_local_path()/restore_path() pair at the > top, and some don't. Is there any reason to be changing sys.path like > this in the test modules? If not, I'll take them out when I see them. The idea behind set_local_path is that it allows running test

[Numpy-discussion] set_local_path in test files

Some test files have a set_local_path()/restore_path() pair at the top, and some don't. Is there any reason to be changing sys.path like this in the test modules? If not, I'll take them out when I see them. Thanks, Alan ___ Numpy-discussion mailing lis

[Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1

Hi, I've seen that NumPy has changed the representation of complex numbers starting with NumPy 1.1. Before, it was: >>> numpy.__version__ '1.0.3' >>> repr(numpy.complex(0))# The Python type '0j' >>> repr(numpy.complex128(0)) # The NumPy type '0j' Now, it is: >>> numpy.__version__ '1.2.0.

Re: [Numpy-discussion] Time to fix ticket #390?

On Sat, Jun 28, 2008 at 04:31:22PM -0600, Charles R Harris wrote: > Questions about ticket #390: Unfortunately, Trac has a problem, it's impossible to view the ticket: SubversionException: ("Can't open file '/home/scipy/svn/numpy/db/revprops/5331

Re: [Numpy-discussion] Should we fix Ticket #709?

On Sun, Jun 29, 2008 at 09:57:52AM -0600, Charles R Harris wrote: Hi, > That's Ticket #709 : > > > I'm faily sure that: > > numpy.isnan(datetime.datetime.now() > > ...should just return False and not raise an exception. IMHO numpy.isnan() makes no