Re: [Numpy-discussion] Documenting `zipf`
On Thu, Jul 24, 2008 at 10:15, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > Hi, > > Does anybody know how Zipf's law or how Zipfian distributions work, > and how they relate > to NumPy's `np.random.zipf`? I'm afraid I can't make head or tail of > these results: > > In [106]: np.random.zipf(2, size=(10)) > Out[106]: array([ 1, 1, 1, 29, 1, 1, 1, 1, 1, 2]) > > (8x1, 1x2, 1x29) > > In [107]: np.random.zipf(2, size=(10)) > Out[107]: array([75, 1, 1, 3, 1, 1, 1, 1, 1, 4]) > > (7x1, 1x3, 1x4, 1x75) > > In [108]: np.random.zipf(2, size=(10)) > Out[108]: array([ 6, 17, 2, 1, 1, 2, 1, 20, 1, 2]) > > (4x1, 3x2, 1x6, 1x17, 1x20) With only 10 samples a piece, it's hard to evaluate what's going on. zipf(s) samples from a Zipfian distribution with N=inf, using the terminology as in the Wikipedia article: http://en.wikipedia.org/wiki/Zipf%27s_law It's a long-tailed distribution, so you would expect to see one or two big numbers with s=2. For example, here is the survival function for the distribution (sf(x) = 1-cdf(x)). In [23]: from numpy import * In [24]: def harmonic_number(s, k): : x = 1.0 / arange(1,k+1) ** s : return x.sum() : In [25]: from scipy.special import zeta In [26]: def sf(x,s): : return 1.0 - harmonic_number(s, int(x)) / zeta(s,1) : In [27]: sf(10, 2.0) Out[27]: 0.057854194645034718 In [28]: sf(20, 2.0) Out[28]: 0.029649105042033996 In [29]: sf(60, 2.0) Out[29]: 0.010048153098031198 -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 1.1.1rc2 tagged
Hello, The 1.1.1rc2 is now available: http://svn.scipy.org/svn/numpy/tags/1.1.1rc2 The source tarball is here: http://cirl.berkeley.edu/numpy/numpy-1.1.1rc2.tar.gz Here is the universal Mac binary: http://cirl.berkeley.edu/numpy/numpy-1.1.1rc2-py2.5-macosx10.5.dmg David Cournapeau will be creating a 1.1.1rc2 Windows binary in next few days. Please test this release ASAP and let us know if there are any problems. If there are no show stoppers, this will likely become the 1.1.1 release. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy fails with multiarray.so: undefined symbol: PyUnicodeUCS2_FromUnicode
Did you build Python from sources in such a way that the Python library is a shared one? I mean, Do you have the file /usr/local/lib/libpython2.5.so ?? On Thu, Jul 24, 2008 at 4:21 AM, G <[EMAIL PROTECTED]> wrote: > Hello, > I have installed the svn version of numpy. I have deleted all previous > versions > of and files related to numpy prior to installing. I also have tried > reinstalling python from source. Regardless, when I try import numpy, I get > the > following: > > Python 2.5.2 (r252:60911, Jul 23 2008, 23:54:29) > [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > import numpy > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 93, in > > >import add_newdocs > File "/usr/local/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, > in >from lib import add_newdoc > File "/usr/local/lib/python2.5/site-packages/numpy/lib/__init__.py", line 4, > > in >from type_check import * > File "/usr/local/lib/python2.5/site-packages/numpy/lib/type_check.py", line > 8, in >import numpy.core.numeric as _nx > File "/usr/local/lib/python2.5/site-packages/numpy/core/__init__.py", > line 5, in >import multiarray > ImportError: /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so: > > undefined symbol: PyUnicodeUCS2_FromUnicode > > > I also tried compiling python using ./configure --enable-unicode=ucs4 > with no luck. > I had python and numpy all working well but then some file got corrupted so I > was forced to reinstall, and I have not yet been able to get things working > again after two days of attempts. > > Thank you, > G > > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Documenting `zipf`
Hi, Does anybody know how Zipf's law or how Zipfian distributions work, and how they relate to NumPy's `np.random.zipf`? I'm afraid I can't make head or tail of these results: In [106]: np.random.zipf(2, size=(10)) Out[106]: array([ 1, 1, 1, 29, 1, 1, 1, 1, 1, 2]) (8x1, 1x2, 1x29) In [107]: np.random.zipf(2, size=(10)) Out[107]: array([75, 1, 1, 3, 1, 1, 1, 1, 1, 4]) (7x1, 1x3, 1x4, 1x75) In [108]: np.random.zipf(2, size=(10)) Out[108]: array([ 6, 17, 2, 1, 1, 2, 1, 20, 1, 2]) (4x1, 3x2, 1x6, 1x17, 1x20) Thanks! Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy fails with multiarray.so: undefined symbol: PyUnicodeUCS2_FromUnicode
G wrote: > Hello, > I have installed the svn version of numpy. I have deleted all previous > versions > of and files related to numpy prior to installing. I also have tried > reinstalling python from source. Regardless, when I try import numpy, I get > the > following: > > Python 2.5.2 (r252:60911, Jul 23 2008, 23:54:29) > [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > import numpy > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 93, in > > > import add_newdocs > File "/usr/local/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, > in > from lib import add_newdoc > File "/usr/local/lib/python2.5/site-packages/numpy/lib/__init__.py", line 4, > > in > from type_check import * > File "/usr/local/lib/python2.5/site-packages/numpy/lib/type_check.py", line > 8, in > import numpy.core.numeric as _nx > File "/usr/local/lib/python2.5/site-packages/numpy/core/__init__.py", > line 5, in > import multiarray > ImportError: /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so: > > undefined symbol: PyUnicodeUCS2_FromUnicode > > This symbol is defined by Python when you build Python with 16-bit unicode support (as opposed to 32-bit) unicode support. Somehow numpy is picking up the 16-bit headers but you probably compiled with ucs4. NumPy supports both UCS2 and UCS4 builds. This looks to me like a Python header installation problem.There are probably some incorrect Python headers being picked up during compilation of NumPy. Can you double check which Python headers are being used (look at the -I lines when NumPy is being built). -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
Andrew Straw wrote: > > The way it's supposed to work, as far as I understand it, is that atlas > is not required at build time but when installed later automatically > speeds up the blas routines. (Upon installation of libatlas3gf-sse2, > libblas.so.3gf is pointed to /usr/lib/sse2/atlas/libblas.so.3gf from > libblas.so.3gf => /usr/lib/libblas.so.3gf). I have not verified that any > of this actually happens. So, please take this with a grain of salt. > Especially since my answer differs from Robert's. > It only happens because debian put the CBLAS interface into libblas.*. Normally, it is not there, and numpy depends on cblas for _dotblas. The way it should work is to test for cblas instead of atlas (atlas always have cblas), but that requires work that nobody has done so far. And this reconcile your answer and Robert's one :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
Eric Firing wrote: > Andrew Straw wrote: > > >> Just for reference, you can find the build dependencies of any Debian >> source package by looking at its .dsc file. For numpy, that can be found >> at http://packages.debian.org/sid/python-numpy >> >> Currently (version 1.1.0, debian version 1:1.1.0-3), that list is: >> >> Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, >> python-central (>= 0.6), gfortran (>= 4:4.2), libblas-dev [!arm !m68k], >> liblapack-dev [!arm !m68k], debhelper (>= 5.0.38), patchutils, >> python-docutils, libfftw3-dev >> >> Build-Conflicts: atlas3-base-dev, libatlas-3dnow-dev, libatlas-base-dev, >> libatlas-headers, libatlas-sse-dev, libatlas-sse2-dev >> > > Do you know why atlas is not used, and is even listed as a conflict? I > have libatlas-sse2 etc. installed on ubuntu hardy, and I routinely build > numpy from source. Maybe the debian specification is for > lowest-common-denominator hardware? The way it's supposed to work, as far as I understand it, is that atlas is not required at build time but when installed later automatically speeds up the blas routines. (Upon installation of libatlas3gf-sse2, libblas.so.3gf is pointed to /usr/lib/sse2/atlas/libblas.so.3gf from libblas.so.3gf => /usr/lib/libblas.so.3gf). I have not verified that any of this actually happens. So, please take this with a grain of salt. Especially since my answer differs from Robert's. -Andrew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Schedule for 1.1.1
On Tue, Jul 15, 2008 at 2:01 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On Mon, Jul 14, 2008 at 10:50 PM, Gael Varoquaux > <[EMAIL PROTECTED]> wrote: >> >> On Sun, Jul 13, 2008 at 01:49:18AM -0700, Jarrod Millman wrote: >> > The NumPy 1.1.1 release date (7/31/08) is rapidly approaching and we >> > need everyone's help. Chuck Harris has volunteered to take the lead >> > on coordinating this release. >> >> Anybody has an idea what the status is on #844? ( >> http://scipy.org/scipy/numpy/ticket/844 ) > > I suspect it is a blas problem, it doesn't show up here. David? I believe it is a bug in ATLAS: http://math-atlas.sourceforge.net/errata3.8.0.html#RMAAT Unfortunately, this means I have to rebuild atlas on windows, which will take time ... cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy fails with multiarray .so: undefined symbol: PyUnicodeUCS2_FromUnico de
Robert Kern gmail.com> writes: > > Are you sure you are getting the same python executable when running > the setup.py as you are when you build numpy? > I believe so: sudo which python /usr/local/bin/python which python /usr/local/bin/python which ipython /usr/local/bin/ipython head /usr/local/bin/ipython #!/usr/local/bin/python I managed to get numpy 1.1.0 to compile and work correctly, so perhaps I somehow have files left around in the svn directory from building with another version of python. I will have to try the svn version again later. Thanks for the suggestion, G ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
Hi, Few months ago I joined a group of system biologist and I have been busy with new projects (mostly C++ based). So I haven't had a chance to work on f2py. However, I am still around to fix f2py bugs and maintain/support numpy.f2py (as long as current numpy maintainers allow it..) -- as a rule these tasks do not take much of my time. I have also rewritten f2py users guide for numpy.f2py and submitted a paper on f2py. I'll make them available when I get some more time.. Regards, still-kicking-yoursly, Pearu On Thu, July 24, 2008 1:46 am, Fernando Perez wrote: > Howdy, > > On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: >> 2008/7/23 Fernando Perez <[EMAIL PROTECTED]>: > >> I agree (with your previous e-mail) that it would be good to have some >> documentation, so if you could give me some pointers on *what* to >> document (I haven't used f2py much), then I'll try my best to get >> around to it. > > Well, I think my 'recap' message earlier in this thread points to a > few issues that can probably be addressed quickly (the 'instead' error > in the help, the doc/docs dichotomy needs to be cleaned up so a single > documentation directory exists, etc). I'm also attaching a set of > very old notes I wrote years ago on f2py that you are free to use in > any way you see fit. I gave them a 2-minute rst treatment but didn't > edit them at all, so they may be somewhat outdated (I originally wrote > them in 2002 I think). > > If Pearu has moved to greener pastures, f2py could certainly use an > adoptive parent. It happens to be a really important piece of > infrastructure and for the most part it works fairly well. I think > a litlte bit of cleanup/doc integration with the rest of numpy is > probably all that's needed, so it could be a good project for someone > to adopt that would potentially be low-demand yet quite useful. > > Cheers, > > f > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy fails with multiarray.so: undefined symbol: PyUnicodeUCS2_FromUnicode
On Thu, Jul 24, 2008 at 02:21, G <[EMAIL PROTECTED]> wrote: > Hello, > I have installed the svn version of numpy. I have deleted all previous > versions > of and files related to numpy prior to installing. I also have tried > reinstalling python from source. Regardless, when I try import numpy, I get > the > following: Are you sure you are getting the same python executable when running the setup.py as you are when you build numpy? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] import numpy fails with multiarray .so: undefined symbol: PyUnicodeUCS2_FromUnicode
Hello, I have installed the svn version of numpy. I have deleted all previous versions of and files related to numpy prior to installing. I also have tried reinstalling python from source. Regardless, when I try import numpy, I get the following: Python 2.5.2 (r252:60911, Jul 23 2008, 23:54:29) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. import numpy Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 93, in import add_newdocs File "/usr/local/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, in from lib import add_newdoc File "/usr/local/lib/python2.5/site-packages/numpy/lib/__init__.py", line 4, in from type_check import * File "/usr/local/lib/python2.5/site-packages/numpy/lib/type_check.py", line 8, in import numpy.core.numeric as _nx File "/usr/local/lib/python2.5/site-packages/numpy/core/__init__.py", line 5, in import multiarray ImportError: /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so: undefined symbol: PyUnicodeUCS2_FromUnicode I also tried compiling python using ./configure --enable-unicode=ucs4 with no luck. I had python and numpy all working well but then some file got corrupted so I was forced to reinstall, and I have not yet been able to get things working again after two days of attempts. Thank you, G ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
On Thu, Jul 24, 2008 at 02:15, Eric Firing <[EMAIL PROTECTED]> wrote: > Andrew Straw wrote: > >> Just for reference, you can find the build dependencies of any Debian >> source package by looking at its .dsc file. For numpy, that can be found >> at http://packages.debian.org/sid/python-numpy >> >> Currently (version 1.1.0, debian version 1:1.1.0-3), that list is: >> >> Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, >> python-central (>= 0.6), gfortran (>= 4:4.2), libblas-dev [!arm !m68k], >> liblapack-dev [!arm !m68k], debhelper (>= 5.0.38), patchutils, >> python-docutils, libfftw3-dev >> >> Build-Conflicts: atlas3-base-dev, libatlas-3dnow-dev, libatlas-base-dev, >> libatlas-headers, libatlas-sse-dev, libatlas-sse2-dev > > Do you know why atlas is not used, and is even listed as a conflict? I > have libatlas-sse2 etc. installed on ubuntu hardy, and I routinely build > numpy from source. Maybe the debian specification is for > lowest-common-denominator hardware? Not quite LCD, but that's close to the truth. Basically, a binary numpy package built against liblapack-dev will work with ATLAS when it is installed. Is suspect that one built against libatlas-base-dev may not work without ATLAS installed. It's specific packaging for Debian-and-spawn, not a general numpy requirement. Which is one reason why looking at a distribution's build-deps is not very useful for inferring details about the dependencies about the upstream packages. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
Andrew Straw wrote: > Just for reference, you can find the build dependencies of any Debian > source package by looking at its .dsc file. For numpy, that can be found > at http://packages.debian.org/sid/python-numpy > > Currently (version 1.1.0, debian version 1:1.1.0-3), that list is: > > Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, > python-central (>= 0.6), gfortran (>= 4:4.2), libblas-dev [!arm !m68k], > liblapack-dev [!arm !m68k], debhelper (>= 5.0.38), patchutils, > python-docutils, libfftw3-dev > > Build-Conflicts: atlas3-base-dev, libatlas-3dnow-dev, libatlas-base-dev, > libatlas-headers, libatlas-sse-dev, libatlas-sse2-dev Do you know why atlas is not used, and is even listed as a conflict? I have libatlas-sse2 etc. installed on ubuntu hardy, and I routinely build numpy from source. Maybe the debian specification is for lowest-common-denominator hardware? Eric ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
