Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 1:43 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > David Cournapeau wrote: > > So it *may* be unrelated to msvc runtime; maybe it just caused a problem > > which has always been there. I will try to see if valgrind says anything > > useful for sparsetools under linux.

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > So it *may* be unrelated to msvc runtime; maybe it just caused a problem > which has always been there. I will try to see if valgrind says anything > useful for sparsetools under linux. > Ok, I think it is unlikely to be caused by msvc runtime problems. Valgrind rep

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

> > > That was in case we publish binaries made with Visual Studio, as David > > asked about this matter. The debugging symbols are indeed different, > > but if it is possible to use Visual Studio, why shouldn't we ? > > > Well, because it is not available freely and is not open source. I am > real

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Quite possibly. Can you run the segfaulting code in a debugger so we > can try to isolate the actual cause? It is possible that we can patch > it up to work with msvcr71. I finally managed to do something, for reference: - I hacked distutils to put -g everywhere (using t

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Matthieu Brucher wrote: > > > 2008/4/18, Robert Kern <[EMAIL PROTECTED] > >: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > <[EMAIL PROTECTED] > > wrote: > > I can help with packaging at least numpy with Visual Studio 20

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 1:15 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > > > 2008/4/18, Robert Kern <[EMAIL PROTECTED]>: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > > <[EMAIL PROTECTED]> wrote: > > > I can help with packaging at least numpy with Visual Studio 2003 (well, > I > >

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

2008/4/18, Robert Kern <[EMAIL PROTECTED]>: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > <[EMAIL PROTECTED]> wrote: > > I can help with packaging at least numpy with Visual Studio 2003 (well, > I > > have to check the EULA if I'm allowed to do that !). For scipy, it is a > > matter of F

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > I can help with packaging at least numpy with Visual Studio 2003 (well, I > have to check the EULA if I'm allowed to do that !). For scipy, it is a > matter of Fortran compiler :| That probably won't work. I believe th

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

2008/4/18, David Cournapeau <[EMAIL PROTECTED]>: > > Robert Kern wrote: > > > > Well, if the official mingw team is committed to not supporting the > > features that we need, then yes, absolutely. This appears to be the > > case. > > > > > Well, this does not seem to work either with gcc 4.3* relea

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > > > Ok, I will have to take a look at how to do that, then, I don't really > have experience with debugger, much less on windows. Will get back one I > understand how this works. > Ok, this is great: when run in gdb, no crash. But when run in cmd.exe, it always cras

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau > <[EMAIL PROTECTED]> wrote: > >> Robert Kern wrote: >> > >> > Well, if the official mingw team is committed to not supporting the >> > features that we need, then yes, absolutely. This appears to be the >> > case. >> >>

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > Well, if the official mingw team is committed to not supporting the > > features that we need, then yes, absolutely. This appears to be the > > case. > > Well, this does not seem to work

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Well, if the official mingw team is committed to not supporting the > features that we need, then yes, absolutely. This appears to be the > case. > Well, this does not seem to work either with gcc 4.3* releases. I got segfaults too. So should we use VS built instead for

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 11:33 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > Question. How does numpy link against the python library when there is only > a static version present? However distutils tells it to. The information is contained in /usr/local/lib/python2.6/config/Makefile, mostly in

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Question. How does numpy link against the python library when there is only a static version present? I compiled/installed python2.6.2a and the only library it generated was /usr/local/lib/python2.6/config/libpython2.6.a. Furthermore, I didn't see the python library specifically linked by any of th

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 10:56 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > It seems that Giovanni is getting his gcc from here: > > > > http://www.tdragon.net/recentgcc/ > > > > which also appears to have gfortran binaries, too. > > Would that be acceptable

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > It seems that Giovanni is getting his gcc from here: > > http://www.tdragon.net/recentgcc/ > > which also appears to have gfortran binaries, too. > > Would that be acceptable to use for numpy/scipy ? I mean, is it enough if we say to people: you need to install mingw f

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > I also found an unofficial installer for gcc 4.*, which at least claim > to care about python: > > http://www.develer.com/oss/GccWinBinaries > > The problems with the new official (but beta) 4.* builds is the lack of

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > > Distutils uses some tests function to see wether a particular set of > float functions is available (FUNCTIONS_TO_CHECK dict in > numpy/core/setup.py), detects a particular set is not available on mingw > (say 'HAVE_INVERSE_HYPERBOLIC'), and define all of them. The pr

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau > <[EMAIL PROTECTED]> wrote: > >> Robert Kern wrote: >> > >> > Ah, this problem again. The build of mingw that you are using were >> > written with msvcrt in mind. For the most part they are compatible >> > with msvcr71,

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > Ah, this problem again. The build of mingw that you are using were > > written with msvcrt in mind. For the most part they are compatible > > with msvcr71, but there are a few places where

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Ah, this problem again. The build of mingw that you are using were > written with msvcrt in mind. For the most part they are compatible > with msvcr71, but there are a few places where they reference a table > that is different between the two runtimes, namely iostream in C++

Re: [Numpy-discussion] Windows/numpy1.0.4 memmap & astype produce loads of warnings on delete

On Thu, Apr 17, 2008 at 4:22 AM, Wim Bakker <[EMAIL PROTECTED]> wrote: > Robert, > > I've replaced my C:\Python24\Lib\site-packages\numpy\core\memmap.py > with the one from http://svn.scipy.org/svn/numpy/trunk/numpy/core/ > and that fixes the problem. > > Thanks for your quick help! > > When

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On 17/04/2008, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > On 17/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote: > > > On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > > > Sorry for the n

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On Thu, Apr 17, 2008 at 5:40 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > On 17/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote: > > > On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > >

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On 17/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > > Sorry for the noise. > > > Don't apologize. That is very odd code. Stefan, is there a rea

Re: [Numpy-discussion] numpy.testing.raises lacks the definition of make_decorator

Thank you ! Matthieu 2008/4/17, Robert Kern <[EMAIL PROTECTED]>: > > On Thu, Apr 17, 2008 at 9:07 AM, Matthieu Brucher > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm trying to use raises with numpy, but when I call nosetests, it tells > me > > that make_decorator is not defined. And indeed, it

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On Thu, Apr 17, 2008 at 3:34 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > On 17/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > > > Sor

Re: [Numpy-discussion] numpy.testing.raises lacks the definition of make_decorator

On Thu, Apr 17, 2008 at 9:07 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to use raises with numpy, but when I call nosetests, it tells me > that make_decorator is not defined. And indeed, it is not defined or > imported in this file, but in nose/tools.py Fixed in r5042. -

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On 17/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > > Sorry for the noise. > > > Don't apologize. That is very odd code. Stefan, is there a rea

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

On Thu, Apr 17, 2008 at 1:21 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Arg! Cancel that! I didn't look carefully enough. How embarrassing! > Sorry for the noise. Don't apologize. That is very odd code. Stefan, is there a reason to form a 1-item tuple then do 1-item tuple unpacking everywher

Re: [Numpy-discussion] bz2

On Thu, Apr 17, 2008 at 2:12 PM, Charles Doutriaux <[EMAIL PROTECTED]> wrote: > Hi, > > Just so you know, yesterday i was doing some test on a fresh ubuntu > installation, trying to figure out the external minimum dependencies for > our system. > > I built (from sources) python (2.5.2) then nu

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 6:34 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Hi, > > I cannot seem to make scipy.sparse works on windows with mingw32, > and it seems related to the msvc runtime. I always get segfaults in the > sparsetools module (c++); if I build the module manually to cont

Re: [Numpy-discussion] Matrix vs ndarray

On 17/04/2008, Santanu Chatterjee <[EMAIL PROTECTED]> wrote: > Hi Numpy users, > I used MATLAB to do numerical calculations for a long time. Recently I > am digging into python and numpy. I am wondering about the following > question : > > 1) What is the difference between ndarray and matrix in

Re: [Numpy-discussion] Matrix vs ndarray

You might find out a lot from reading through this page: http://www.scipy.org/NumPy_for_Matlab_Users What I think that doesn't say is why the two classes are needed in NumPy. Basically, the reason for that is that Matlab has .* and * which mean different things, but Python only has the one * ope

Re: [Numpy-discussion] Matrix vs ndarray

On Thu, 17 Apr 2008, Santanu Chatterjee apparently wrote: > 1) What is the difference between ndarray and matrix in > numpy? My idea is that having N-dimensional array is > sufficient (of course a MATLAB users point of view). If > anyone can provide some idea, I will appreciate it. Matrices ar

[Numpy-discussion] bz2

Hi, Just so you know, yesterday i was doing some test on a fresh ubuntu installation, trying to figure out the external minimum dependencies for our system. I built (from sources) python (2.5.2) then numpy. All seemed ok, but when importing numpy i had an error, trying to import module bz2

[Numpy-discussion] Matrix vs ndarray

Hi Numpy users, I used MATLAB to do numerical calculations for a long time. Recently I am digging into python and numpy. I am wondering about the following question : 1) What is the difference between ndarray and matrix in numpy? My idea is that having N-dimensional array is sufficient (of cou

Re: [Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

Arg! Cancel that! I didn't look carefully enough. How embarrassing! Sorry for the noise. Eric Eric Firing wrote: > While trying to figure out how to write tests for "take", I stumbled > across this in numpy.core.tests.test_multiarray.py: > > class TestScalarIndexing(NumpyTestCase): > d

Re: [Numpy-discussion] Fast histogram

Combining Sebastian and Jae-Joon's suggestions, I have something that might work: >>> timeit numpy.bincount(array.flat) 10 loops, best of 3: 28.2 ms per loop This is close enough to video-rate... And I can then combine bins as needed to get a particular bin count/range after the fact. Thank

[Numpy-discussion] broken numpy.core.tests.test_multiarray.TestScalarIndexing.SetUp

While trying to figure out how to write tests for "take", I stumbled across this in numpy.core.tests.test_multiarray.py: class TestScalarIndexing(NumpyTestCase): def setUp(self): self.d = array([0,1])[0], def check_ellipsis_subscript(self): a, = self.d self.f

Re: [Numpy-discussion] Fast histogram

Hello, >> But even if indices = array, one still needs to do something like: >> for index in indices: histogram[index] += 1 > numpy.bincount? That is indeed what I was looking for! I knew I'd seen such a function. However, the speed is a bit disappointing. I guess the sorting isn't too much of

Re: [Numpy-discussion] Fast histogram

Hi Zach, I have a similar loop which I wrote using scipy.weave. This was my first foray into weave, and I had to dig through the intermediate C sources to find the macros that did the indexing in the way I make use of here, but this snipped may get you started. There are 2 functions, which each do

[Numpy-discussion] Fwd: Fast histogram

On 17/04/2008, Zachary Pincus wrote: > But even if indices = array, one still needs to do something like: > for index in indices: histogram[index] += 1 > > Which is slow in python and fast in C. > I haven't tried this, but if you want the sum in C you could do for x in unique(indices):

Re: [Numpy-discussion] /usr/bin/python: double free or corruption

Eric Emsellem wrote: > Hi, > > I just installed a new openSuse 10.3, python, numpy, etc, on a 32 bit PC > (using > the rpm provide on the science Suse repository) > > When using numpy.fromfile, I get a glibc error when it tries to read something > which is not there (end of the file). > So for exa

Re: [Numpy-discussion] Fast histogram

On 17/04/2008, Zachary Pincus wrote: > But even if indices = array, one still needs to do something like: > for index in indices: histogram[index] += 1 > > Which is slow in python and fast in C. > I haven't tried this, but if you want the sum in C you could do for x in unique(indices): his

Re: [Numpy-discussion] Fast histogram

> But even if indices = array, one still needs to do something like: > for index in indices: histogram[index] += 1 > > Which is slow in python and fast in C. > > I'm guessing that there's no utility function in numpy that does a > loop like this? If so, that would be handy, but if now, I think

[Numpy-discussion] /usr/bin/python: double free or corruption

Hi, I just installed a new openSuse 10.3, python, numpy, etc, on a 32 bit PC (using the rpm provide on the science Suse repository) When using numpy.fromfile, I get a glibc error when it tries to read something which is not there (end of the file). So for example with a file "tmp" which has nothi

Re: [Numpy-discussion] Fast histogram

>> But even if indices = array, one still needs to do something like: >> for index in indices: histogram[index] += 1 >> >> Which is slow in python and fast in C. >> >> > I thought of a broadcasting approach... what are the chances that a > simple > > bins[:] = 0 > bins[ img.flat ] += 1 That does

Re: [Numpy-discussion] Fast histogram

On Thu, Apr 17, 2008 at 6:54 PM, Zachary Pincus <[EMAIL PROTECTED]> wrote: > Hi, and thanks for the suggestion! > > > > How many bits per pixel does your camera actually generate !? > > If its for example a 12 bit camera, you could just fill in directly > > into 4096 preallocated bins. > > You

Re: [Numpy-discussion] Fast histogram

Hi, and thanks for the suggestion! > How many bits per pixel does your camera actually generate !? > If its for example a 12 bit camera, you could just fill in directly > into 4096 preallocated bins. > You would not need any sorting !! > That's what I did for a 16 bit camera -- but I wrote it in C

Re: [Numpy-discussion] Fast histogram

Hi, > How about a combination of sort, followed by searchsorted right/left > using the bin boundaries as keys? The difference of the two > resulting vectors is the bin value. Something like: > > In [1]: data = arange(100) > > In [2]: bins = [0,10,50,70,100] > > In [3]: lind = data.searchsorted

Re: [Numpy-discussion] Fast histogram

On Thu, Apr 17, 2008 at 6:18 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On Thu, Apr 17, 2008 at 10:02 AM, Zachary Pincus <[EMAIL PROTECTED]> > wrote: > > Hi folks, > > > > I'm working on a live-video display for some microscope control tools > > I'm building. For this, I need a fast his

Re: [Numpy-discussion] Fast histogram

On Thu, Apr 17, 2008 at 10:02 AM, Zachary Pincus <[EMAIL PROTECTED]> wrote: > Hi folks, > > I'm working on a live-video display for some microscope control tools > I'm building. For this, I need a fast histogram function to work on > large-ish images (1000x2000 or so) at video rate, with cycles l

[Numpy-discussion] Fast histogram

Hi folks, I'm working on a live-video display for some microscope control tools I'm building. For this, I need a fast histogram function to work on large-ish images (1000x2000 or so) at video rate, with cycles left over for more interesting calculations (like autofocus). Now, numpy.histogr

Re: [Numpy-discussion] Release of NumPy

Since I am the one who initially proposed the RowVector/ColumnVector idea, I have followed the discussion here with interest. However, since I typically deal with sparse matrices, I didn't feel like I had much to contribute to the indexing issues. But now that we are getting into sparse m

Re: [Numpy-discussion] Release of NumPy

Alan G Isaac wrote: >> On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote: >> >>> - it retains more ndarray behavior >>> > > > On Thu, 17 Apr 2008, Stéfan van der Walt apparently wrote: > >> That is simply not true. The patch I sent provides everything you >> asked for w

Re: [Numpy-discussion] Release of NumPy

> On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote: >> - it retains more ndarray behavior On Thu, 17 Apr 2008, Stéfan van der Walt apparently wrote: > That is simply not true. The patch I sent provides everything you > asked for without breaking any ndarray behaviour, whereas your

[Numpy-discussion] numpy.testing.raises lacks the definition of make_decorator

Hi, I'm trying to use raises with numpy, but when I call nosetests, it tells me that make_decorator is not defined. And indeed, it is not defined or imported in this file, but in nose/tools.py Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.ei

[Numpy-discussion] Distutils: using different linker options for c++ and c code

Hi, I cannot seem to make scipy.sparse works on windows with mingw32, and it seems related to the msvc runtime. I always get segfaults in the sparsetools module (c++); if I build the module manually to control the options precisely and remove the -lmsvc71 from the build command, I cannot r

Re: [Numpy-discussion] Release of NumPy

Hi Joris On 17/04/2008, Joris De Ridder <[EMAIL PROTECTED]> wrote: > The patch introduces "Vector", but I assume it's your intend to change > this into "RowVector" or "ColumnVector" in the end, correct? This was just of a proof of concept. It depends very much on what you guys want. Vector curr

Re: [Numpy-discussion] Release of NumPy

On 17/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > I have mixed feelings on all of this discussion. I do want to make > sure, however, that two ideas are considered: > > 1) How will sparse matrices behave? It seems to me that the matrix > object and sparse matrices should behave id

Re: [Numpy-discussion] Release of NumPy

On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote: > Stefan's scores well too, so why do I prefer mine? > As I said, I am not sure mine is better, but I think it is, > an I can offer some reasons to prefer it. Two are: > > - it is simpler > - it retains more ndarray behavior

Re: [Numpy-discussion] Segmentation fault

Thanks a lot for your answer ! I will try another way ! Anne-Sophie David Cournapeau a écrit : > David Cournapeau wrote: >> Unless you are executing this on a gigantic computer, this won't work >> very well: you are asking to create an array which has ~ 2e5^2 elements, >> that is around 40 Gb.

Re: [Numpy-discussion] sort

On Thu, Apr 17, 2008 at 03:18:45AM -0700, wilson wrote: > i have a 1 dimensional array of floats that i want to sort in > descending order.i did as follows > from numpy import tolist,array,sort > y=array([..]) #may be 1000 items > z=sort(y) > l=z.tolist() > l.reverse() > rl=array(l) > now rl

Re: [Numpy-discussion] sort

On Thu, Apr 17, 2008 at 5:18 AM, wilson <[EMAIL PROTECTED]> wrote: > i have a 1 dimensional array of floats that i want to sort in > descending order.i did as follows > > from numpy import tolist,array,sort > y=array([..]) #may be 1000 items > z=sort(y) > l=z.tolist() > l.reverse() > rl=

[Numpy-discussion] sort

i have a 1 dimensional array of floats that i want to sort in descending order.i did as follows from numpy import tolist,array,sort y=array([..]) #may be 1000 items z=sort(y) l=z.tolist() l.reverse() rl=array(l) now rl is a 1 dim array sorted in descending order. but i am looking for a better

Re: [Numpy-discussion] Segmentation fault

David Cournapeau wrote: > > Unless you are executing this on a gigantic computer, this won't work > very well: you are asking to create an array which has ~ 2e5^2 elements, > that is around 40 Gb. > > There is a bug, but the bug happens at the above line: the zeros call > did not fail whereas it

Re: [Numpy-discussion] Segmentation fault

Anne-Sophie Sertier wrote: > Hello ! > > I'm a new user of Numpy. I want to use it to work with matrices (very > huge matrices), select column, make product, etc ... > Configuration : Debian, python 2.4.4 and numpy 1.0.1 > > So here is my problem: > I initialize a matrix which will contain only 0 a

Re: [Numpy-discussion] Release of NumPy

On 17 Apr 2008, at 01:09, Stéfan van der Walt wrote: > Split infinitive -- I'd get in trouble for that. > > Please use the latest patch (attached), which fixes a bug with > assignment. > > I experimented with returning an (N,) array when converting using > vector.A, but I'm not convinced that t

Re: [Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas

> I am guessing that he built the cblas interface from here: > > http://www.netlib.org/blas/blast-forum/cblas.tgz > > Note that this is same C interface provided by ATLAS, the MKL, and > GOTO and is *not* the version simply converted from the FORTRAN using > f2c. It calls the (hopefully accele

[Numpy-discussion] Segmentation fault

Hello ! I'm a new user of Numpy. I want to use it to work with matrices (very huge matrices), select column, make product, etc ... Configuration : Debian, python 2.4.4 and numpy 1.0.1 So here is my problem: I initialize a matrix which will contain only 0 and 1 >>> from numpy import * >>> matCon

Re: [Numpy-discussion] Windows/numpy1.0.4 memmap & astype produce loads of warnings on delete

Robert, I've replaced my C:\Python24\Lib\site-packages\numpy\core\memmap.py with the one from http://svn.scipy.org/svn/numpy/trunk/numpy/core/ and that fixes the problem. Thanks for your quick help! When is the new version of numpy due? Wim Bakker Any garbage below this line is not mine. -- I

Re: [Numpy-discussion] Windows/numpy1.0.4 memmap & astype produce loads of warnings on delete

On Thu, Apr 17, 2008 at 3:10 AM, Wim Bakker <[EMAIL PROTECTED]> wrote: > The last version of numpy gives me headaches. I've been able to trace > the problem to the use of astype(). When a memmap is deleted I get the > following warning: > > Exception exceptions.ValueError: 'mmap closed or invali

[Numpy-discussion] Windows/numpy1.0.4 memmap & astype produce loads of warnings on delete

The last version of numpy gives me headaches. I've been able to trace the problem to the use of astype(). When a memmap is deleted I get the following warning: Exception exceptions.ValueError: 'mmap closed or invalid' in ignored The memmap still seems to work but these error messages slow don't

[Numpy-discussion] Strange behaviour of linalg.svd() and linalg.eigh()

Hi, Ive implemented the classical MultiDimensional Scaling for the scikit learn using both functions. Their behavior surprised me for "big" arrays (1 by 1, symmetric as it is a similarity matrix). linalg.svd() raises a memory error because it tries to allocate a (700,) array (in fact b