Re: [Numpy-discussion] typo in docs

On Jun 8, 2010, at 4:37 AM, Sebastian Haase wrote: > another note: > http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#arrays-indexing-rec > should not say "record array" - because recarray a "special" in that > they can even access the named fields via attribute access rather > than

Re: [Numpy-discussion] updating NumPy in EPD

Jeff Hsu wrote: > Check which version of numpy python is importing with "import numpy; > printnumpy.__file__". I had a similar question and this worked after I > removed that installation of numpy. I think the enthought distro > installs it somewhere else that has priority. Ah, this was t

Re: [Numpy-discussion] updating NumPy in EPD

Check which version of numpy python is importing with "import numpy; print numpy.__file__". I had a similar question and this worked after I removed that installation of numpy. I think the enthought distro installs it somewhere else that has priority. On Tue, Jun 8, 2010 at 10:30 PM, Nick Matzk

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 3:49 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrot > 2010/6/8 Anne Archibald : > > Numpy arrays can have any configuration of memory strides, including > > some that are zero; C and Fortran contiguous arrays are simply those > > that have special arrangements of

[Numpy-discussion] updating NumPy in EPD

Hi NumPy gurus, I have a slightly weird question. I would like to install the PyCogent python library. However, this requires NumPy 1.3 or higher. I only have NumPy 1.1.1, because I got it as part of the Enthought Python Distribution (4.1) back in 2008. Now, when I download & install a new

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

Have any of you built py 3.1.2 from source on a mac? Vincent On Tue, Jun 8, 2010 at 6:56 PM, David wrote: > On 06/09/2010 08:04 AM, Vincent Davis wrote: >> I do have limits.h in 10.4 sdk >> >> So what next. Ay Ideas? >> I had tried to build py 3.1.2 from source but that did not work either. > > I

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

On 06/09/2010 08:04 AM, Vincent Davis wrote: > I do have limits.h in 10.4 sdk > > So what next. Ay Ideas? > I had tried to build py 3.1.2 from source but that did not work either. I had the same issue when I tried the python 3 branch on mac os x. I have not found the issue yet, but I am afraid it

Re: [Numpy-discussion] Greater common divisor

On Mon, Jun 7, 2010 at 4:19 AM, Daniele Nicolodi wrote: > Hello. There is a method in numpy to compute the greater common divisor > of the elements of an array? Searching through the documentation I > didn't find it. > > If you need to do more complicated stuff based around the GCD, like finding

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

I do have limits.h in 10.4 sdk So what next. Ay Ideas? I had tried to build py 3.1.2 from source but that did not work either. Thanks Vincent On Tue, Jun 8, 2010 at 3:15 PM, Zachary Pincus wrote: > Hi Vincent, > > I'm not really sure -- now the build is using the 10.4 SDK but still > not findin

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

2010/6/8 Anne Archibald : > Numpy arrays can have any configuration of memory strides, including > some that are zero; C and Fortran contiguous arrays are simply those > that have special arrangements of the strides. The actual stride > values is normally almost irrelevant to python code. First, I

Re: [Numpy-discussion] Mail list idea

On 8 June 2010 11:13, Vincent Davis wrote: > 2) A web based interface that is similar to stackoverflow in that a > user can search and post within the same page and as they type a > question suggested relevant posts are shown. Also have a look at ask.scipy.org. Cheers Stéfan

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On 8 June 2010 17:17, David Goldsmith wrote: > On Tue, Jun 8, 2010 at 1:56 PM, Benjamin Root wrote: >> >> On Tue, Jun 8, 2010 at 1:36 PM, Eric Firing wrote: >>> >>> On 06/08/2010 08:16 AM, Eric Firing wrote: >>> > On 06/08/2010 05:50 AM, Charles R Harris wrote: >>> >> >>> >> On Tue, Jun 8, 2010

Re: [Numpy-discussion] Greater common divisor

googling for greatest common divisor OR denominator numpy OR scipy OR python I found this: http://projects.scipy.org/numpy/browser/trunk/numpy/core/_internal.py?rev=8316 554 def _gcd(a, b): 555 """Calculate the greatest common divisor of a and b""" 556 while b: 557

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 1:56 PM, Benjamin Root wrote: > > On Tue, Jun 8, 2010 at 1:36 PM, Eric Firing wrote: > >> On 06/08/2010 08:16 AM, Eric Firing wrote: >> > On 06/08/2010 05:50 AM, Charles R Harris wrote: >> >> >> >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith< >> d.l.goldsm...@gmail.com

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

Hi Vincent, I'm not really sure -- now the build is using the 10.4 SDK but still not finding the right headers. Could you check to see that the following file exists: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/limits.h If it does, then I'm really not sure what's going on. Zach On Jun 8, 2

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 1:36 PM, Eric Firing wrote: > On 06/08/2010 08:16 AM, Eric Firing wrote: > > On 06/08/2010 05:50 AM, Charles R Harris wrote: > >> > >> > >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith >> > wrote: > >> > >> On Tue, Jun 8, 2010 at 8:2

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 12:05 PM, Anne Archibald wrote: > On 8 June 2010 14:16, Eric Firing wrote: > > On 06/08/2010 05:50 AM, Charles R Harris wrote: > >> > >> > >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith < > d.l.goldsm...@gmail.com > >> > wrote: > >> > >>

Re: [Numpy-discussion] np.choose() question

Hi, actually, I meant to reply to Mark's mail, as I used his solution ;) Thanks! On 06/08/2010 09:21 PM, Gökhan Sever wrote: > If we were at so or ask.scipy I would vote for Mark's solution :) > > Usually in cases like yours, I tend to use the shortest version of the > solutions. > > On Tue, J

Re: [Numpy-discussion] np.choose() question

On Tue, Jun 8, 2010 at 2:32 PM, Hans Meine wrote: > > > Funny, that's exactly what I wanted to do (idx being a label/region image > here), > and what I tried today. > > You will be happy to hear that the even simpler solution is to just use > fancy indexing (the name is justified here): > > times[

Re: [Numpy-discussion] np.choose() question

Hi! Am 08.06.2010 um 18:24 schrieb Andreas Hilboll: > I have an array idx, which holds int values and has a 2d shape. All > values inside idx are 0 <= idx < n. And I have a second array times, > which is 1d, with times.shape = (n,). > > Out of these two arrays I now want to create a 2d array ha

Re: [Numpy-discussion] np.choose() question

If we were at so or ask.scipy I would vote for Mark's solution :) Usually in cases like yours, I tend to use the shortest version of the solutions. On Tue, Jun 8, 2010 at 2:08 PM, Andreas Hilboll wrote: > Hi, > > > newtimes = [times[idx[x][y]] for x in range(2) for y in range(2)] > > np.array(n

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On 8 June 2010 14:16, Eric Firing wrote: > On 06/08/2010 05:50 AM, Charles R Harris wrote: >> >> >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith > > wrote: >> >> On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant > > wrote: >> >> >>

Re: [Numpy-discussion] np.choose() question

Hi, > newtimes = [times[idx[x][y]] for x in range(2) for y in range(2)] > np.array(newtimes).reshape(2,2) > array([[104, 102], >[103, 101]]) Great, thanks a lot! Cheers, Andreas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.or

Re: [Numpy-discussion] Memory Usage Question - clarification

In fact, 'report_memory' shows that memory use was constant throughout all 256 iterations. Thank you for the hint, Eric. > Date: Tue, 08 Jun 2010 09:22:41 -0700 > From: Tom Kuiper > Subject: Re: [Numpy-discussion] Memory Usage Question > To: "numpy-discussion@scipy.org" > ... > Memory still

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On 06/08/2010 08:16 AM, Eric Firing wrote: > On 06/08/2010 05:50 AM, Charles R Harris wrote: >> >> >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith> > wrote: >> >> On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant> > wrote: >> >>

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

> Failed again, I have attached the output including the execution of > the above commands. > Thanks for link to the environment variables, I need to read that. In the attached file (and the one from the next email too) I didn't see the MACOSX_DEPLOYMENT_TARGET=10.4 export MACOSX_DEPLOYMENT_TA

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On 06/08/2010 05:50 AM, Charles R Harris wrote: > > > On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith > wrote: > > On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant > wrote: > > > > > Correct me if I am wrong, but the paragra

Re: [Numpy-discussion] np.choose() question

Not pretty, but it works: >>> idx array([[4, 2], [3, 1]]) >>> times array([100, 101, 102, 103, 104]) >>> numpy.reshape(times[idx.flatten()],idx.shape) array([[104, 102], [103, 101]]) >>> On Tue, Jun 8, 2010 at 10:09 AM, Gökhan Sever wrote: > > > On Tue, Jun 8, 2010 at 1

Re: [Numpy-discussion] Problems with get_info installing scipy

Thanks, that works. Unfortunately it uncovered another problem. When I try and reinstall numpy, it keeps building with intel mkl libraries even when I get a fresh install of numpy with the site.cfg set to default or no site.cfg at all. Giving me: FOUND: libraries = ['mkl_intel_lp64', 'mkl_in

[Numpy-discussion] Mail list idea

I accidentally posted this on scipy list also, I meant it to be here since we already have a tread going about the mail list and I now know there is a moderator :) I prefer the mail list but stackoverflow.com is good. But what I really like about stackoverflow is not the answers but the ability to

Re: [Numpy-discussion] np.choose() question

On Tue, Jun 8, 2010 at 11:24 AM, Andreas Hilboll wrote: > Hi there, > > I have a problem, which I'm sure can somehow be solved using np.choose() > - but I cannot figure out how :( > > I have an array idx, which holds int values and has a 2d shape. All > values inside idx are 0 <= idx < n. And I h

Re: [Numpy-discussion] Memory Usage Question

Dear Eric, thank you for the insight and suggestion. Reading between the lines I developed the suspicion that the problem might be in the extension function 'unpack_vdr_data'. Previously the last part of that was Cmplx = PyComplex_FromCComplex(cmplx); if (PyList_SetItem(Clist, tim

[Numpy-discussion] np.choose() question

Hi there, I have a problem, which I'm sure can somehow be solved using np.choose() - but I cannot figure out how :( I have an array idx, which holds int values and has a 2d shape. All values inside idx are 0 <= idx < n. And I have a second array times, which is 1d, with times.shape = (n,). Ou

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

> On Tue, Jun 8, 2010 at 7:58 AM, Zachary Pincus > wrote: >> This is unexpected, from the error log: >>> /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ >>> Python.h:11:20: error: limits.h: No such file or directory >> >> No good... it can't find basic system headers. Perhaps

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 8:43 AM, John Hunter wrote: > On Tue, Jun 8, 2010 at 10:33 AM, Sebastian Haase > wrote: > > On Tue, Jun 8, 2010 at 5:23 PM, David Goldsmith > wrote: > >> On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase > >> wrote: > >>> > >>> I don't want to complain > >>> But what

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith wrote: > On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant wrote: > >> >> > > Correct me if I am wrong, but the paragraph >> > > >> > > Note to those used to IDL or Fortran memory order as it relates to >> > > indexing. Numpy uses C-order indexing. That

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 10:33 AM, Sebastian Haase wrote: > On Tue, Jun 8, 2010 at 5:23 PM, David Goldsmith > wrote: >> On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase >> wrote: >>> >>> I don't want to complain >>> But what is wrong with a limit of 40kB ? There are enough places where >>> o

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant wrote: > > > > Correct me if I am wrong, but the paragraph > > > > > > Note to those used to IDL or Fortran memory order as it relates to > > > indexing. Numpy uses C-order indexing. That means that the last index > > > usually (see xxx for exceptions)

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 9:27 AM, Pavel Bazant wrote: > > > > Correct me if I am wrong, but the paragraph > > > > > > Note to those used to IDL or Fortran memory order as it relates to > > > indexing. Numpy uses C-order indexing. That means that the last index > > > usually (see xxx for exceptions)

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 5:23 PM, David Goldsmith wrote: > On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase > wrote: >> >> I don't want to complain >> But what is wrong with a limit of 40kB ? There are enough places where >> one could upload larger files for everyone interested... > > Not ever

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

> > Correct me if I am wrong, but the paragraph > > > > Note to those used to IDL or Fortran memory order as it relates to > > indexing. Numpy uses C-order indexing. That means that the last index > > usually (see xxx for exceptions) represents the most rapidly changing memory > > location, unlike

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase wrote: > I don't want to complain > But what is wrong with a limit of 40kB ? There are enough places where > one could upload larger files for everyone interested... > Not everyone knows about 'em, though - can you list some here, please. Than

[Numpy-discussion] NumPy equivalent to PyFloat_Check

I am working in C, and I want to check whether a Python object (PyObject*) is a numpy float object. i.e. numpy.float32, numpy.float64 etc. I have looked at the docs and the NumPy Manual Part II C-API, but I am not sure which of the many type checking functions to use. Could someone please give

Re: [Numpy-discussion] Reading 12bits numbers ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nadav Horesh skrev: > You can. If each number occupies 2 bytes (16 bits) it is straight > forward. If it is a continues 12 bits stream you have to unpack by your > self: > > data = np.fromstring(str12bits, dtype=np.uint8) > data1 = data.astype(no.uint

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

On Tue, Jun 8, 2010 at 7:58 AM, Zachary Pincus wrote: > This is unexpected, from the error log: >> /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ >> Python.h:11:20: error: limits.h: No such file or directory > > No good... it can't find basic system headers. Perhaps it's due

Re: [Numpy-discussion] Problems with get_info installing scipy

Tue, 08 Jun 2010 09:47:41 -0400, Jeff Hsu wrote: > I tried to install scipy, but I get the error with not being able to > find get_info() from numpy.distutils.misc_util. I read that you need > the SVN version of numpy to fix this. I recompiled numpy and > reinstalled from the SVN, which says is v

Re: [Numpy-discussion] Installing numpy on py 3.1.2 , osx

This is unexpected, from the error log: > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > Python.h:11:20: error: limits.h: No such file or directory No good... it can't find basic system headers. Perhaps it's due to the MACOSX_DEPLOYMENT_TARGET environment variable that w

[Numpy-discussion] Problems with get_info installing scipy

I tried to install scipy, but I get the error with not being able to find get_info() from numpy.distutils.misc_util. I read that you need the SVN version of numpy to fix this. I recompiled numpy and reinstalled from the SVN, which says is version 1.3.0 (was using 1.4.1 version before) and that fu

Re: [Numpy-discussion] Reading 12bits numbers ?

You can. If each number occupies 2 bytes (16 bits) it is straight forward. If it is a continues 12 bits stream you have to unpack by your self: data = np.fromstring(str12bits, dtype=np.uint8) data1 = data.astype(no.uint16) data1[::3] = data1[::3]*256 + data1[1::3] // 16 data1[1::3] = (data[1::3] &

[Numpy-discussion] Reading 12bits numbers ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Is it possible to read an array of 12bit encoded numbers from file (or string) using numpy ? Thanks, Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEB

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

>2010/6/8 Hans Meine : > On Tuesday 08 June 2010 11:40:59 Scott Sinclair wrote: >> The savez docstring should probably be clarified to provide this >> information. > > I would prefer to actually offer compression to the user. In the meantime, I've edited the docstring to reflect the current behavi

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Mon, Jun 7, 2010 at 5:52 AM, Pavel Bazant wrote: > Correct me if I am wrong, but the paragraph > > Note to those used to IDL or Fortran memory order as it relates to > indexing. Numpy uses C-order indexing. That means that the last index > usually (see xxx for exceptions) represents the most r

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

Hi Anne, thanks for your input, too. On Tuesday 08 June 2010 12:53:51 Anne Archibald wrote: > I'm also a little dubious about making compression the default. > np.savez provides a feature - storing multiple arrays - that is not > otherwise available. I suspect many users care more about speed th

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

On 8 June 2010 06:11, Pauli Virtanen wrote: > ti, 2010-06-08 kello 12:03 +0200, Hans Meine kirjoitti: >> On Tuesday 08 June 2010 11:40:59 Scott Sinclair wrote: >> > The savez docstring should probably be clarified to provide this >> > information. >> >> I would prefer to actually offer compression

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

On Tuesday 08 June 2010 12:11:28 Pauli Virtanen wrote: > ti, 2010-06-08 kello 12:03 +0200, Hans Meine kirjoitti: > > I would prefer to actually offer compression to the user. Unfortunately, > > adding another argument to this function will never be 100% secure, since > > currently, all kwargs will

[Numpy-discussion] np.append converts recarray to ndarray -- np.insert works

Hi, Is there a reason that np.append converts recarray to ndarray while np.insert keeps recarray: >>> type(a) >>> type(N.append(a,a)) >>> type(N.insert(a,-1, a)) Thanks, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org ht

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

ti, 2010-06-08 kello 12:03 +0200, Hans Meine kirjoitti: > On Tuesday 08 June 2010 11:40:59 Scott Sinclair wrote: > > The savez docstring should probably be clarified to provide this > > information. > > I would prefer to actually offer compression to the user. Unfortunately, > adding another argu

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

On Tuesday 08 June 2010 11:40:59 Scott Sinclair wrote: > The savez docstring should probably be clarified to provide this > information. I would prefer to actually offer compression to the user. Unfortunately, adding another argument to this function will never be 100% secure, since currently,

Re: [Numpy-discussion] numpy.savez does /not/ compress!?

>2010/6/8 Hans Meine : > I just wondered why numpy.load("foo.npz") was so much faster than loading > (gzip-compressed) hdf5 file contents, and found that numpy.savez did not > compress my files at all. > > But is that intended?  The numpy.savez docstring says "Save several arrays > into a single, *

[Numpy-discussion] python setup.py bdist --format=rpm

Hi all, I tried to build a rpm of numpy using python setup.py bdist --format=rpm removing 'numpy-2.0.0.dev8460' (and everything under it) copying dist/numpy-2.0.0.dev8460.tar.gz -> build/bdist.linux-x86_64/rpm/SOURCES building RPMs rpm -ba --define _topdir /data/home/nwagner/svn/numpy/build/bd

Re: [Numpy-discussion] typo in docs

>On 8 June 2010 09:46, Sebastian Haase wrote: > Hi, > > http://docs.scipy.org/doc/numpy/reference/arrays.dtypes.html#specifying-and-constructing-data-types > > says "f2" instead of "f1" > > Numarray introduced a short-hand notation for specifying the format of > a record as a comma-separated strin

Re: [Numpy-discussion] typo in docs

another note: http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#arrays-indexing-rec should not say "record array" - because recarray a "special" in that they can even access the named fields via attribute access rather than using the dictionary-like syntax. -S. PS: I guess I should h

[Numpy-discussion] numpy.savez does /not/ compress!?

Hi, I just wondered why numpy.load("foo.npz") was so much faster than loading (gzip-compressed) hdf5 file contents, and found that numpy.savez did not compress my files at all. So there is currently no point in using numpy.savez instead of numpy.save when you're not using the multiple-arrays-p

[Numpy-discussion] typo in docs

Hi, http://docs.scipy.org/doc/numpy/reference/arrays.dtypes.html#specifying-and-constructing-data-types says "f2" instead of "f1" Numarray introduced a short-hand notation for specifying the format of a record as a comma-separated string of basic formats. ... The generated data-type fields are n

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

I don't want to complain But what is wrong with a limit of 40kB ? There are enough places where one could upload larger files for everyone interested... My 2 cents, Sebastian Haase PS: what is the limit now set to ? On Mon, Jun 7, 2010 at 11:24 PM, Vincent Davis wrote: > On Mon, Jun 7,