Mailman 3 April 2010 - NumPy-Discussion

Aggregate memmap
by Matthew Turk 25 Apr '10

25 Apr '10

Hi there, I've quite a bit of unformatted fortran data that I'd like to use as input to a memmap, as sort of a staging area for selection of subregions to be loaded into RAM. Unfortunately, what I'm running into is that the data was output as a set of "slices" through a 3D cube, instead of a single 3D cube -- the end result being that each slice also contains a record delimiter. I was wondering if there's a way to either specify that every traversal through the least-frequent dimension requires an additional offset or to calculate individual offsets for each slice myself and then aggregate these into a "super memmap." Thanks for any suggestions you might have! -Matt

4 5

Disabling Extended Precision in NumPy (like -ffloat-store)
by Adrien Guillon 25 Apr '10

25 Apr '10

Hello all, I've recently started to use NumPy to prototype some numerical algorithms, which will eventually find their way to a GPU (where I want to limit myself to single-precision operations for performance reasons). I have recently switched to the use of the "single" type in NumPy to ensure I use single-precision floating point operations. My understanding, however, is that Intel processors may use extended precision for some operations anyways unless this is explicitly disabled, which is done with gcc via the -ffloat-store operation. Since I am prototyping algorithms for a different processor architecture, where the extended precision registers simply do not exist, I would really like to force NumPy to limit itself to using single-precision operations throughout the calculation (no extended precision in registers). How can I do this? Thanks! AJ

9 11

toydist: Using manually after build system now?
by Dag Sverre Seljebotn 25 Apr '10

25 Apr '10

(The toydist manual says to use this list, so here I go...) Is it possible to invoke toydist manually to install something built manually with a build system? How is the final .info specification supposed to look like when toysetup is coupled with a build system? I tried this: Library: Packages: healpix Extension: healpix.lib Sources: healpix/lib.so but it didn't work (invokes gcc on .so file). Will it perhaps be something like this: Library: Packages: healpix Extension: healpix.lib Built: build/something/lib.so in toydist 0.3 or 0.4? Dag Sverre

2 1

Patches for review cleanup.
by Charles R Harris 24 Apr '10

24 Apr '10

Hi folks, There are a lot of patches sitting around waiting for review. I think most can be taken care of pretty quickly and closed. There are, however, a half dozen or so small patches relating to distutils that someone familiar with that part of numpy should go over (David?). Anyway, lets get that queue cleaned out. Chuck

1 0

Re: [Numpy-discussion] My GSoC Proposal to Implement a Subset of NumPy for PyPy
by Dan Roberts 23 Apr '10

23 Apr '10

Wow, that's a very cool idea. I think that's an excellent approach to allowing user RPython functions. Maciej expressed concern this could create a support burden for RPython for the core PyPy developers (There aren't many of them). I think, handled correctly, this could help create a community knowledgable about RPython that could support it, but initially I would be the only one supporting this use. I think the best approach would be to provide a similar fast_vectorize() in addition to accelerating normal python looping constructs with the JIT compiler, that way we can have faster code without even trying. I'm going to be contacting the author of that paper to see what its implementation status is, as the paper mentioned he was trying to get it into SciPy. Sorry about the latency, I tend to make multiple drafts of my emails before I send them... On Apr 21, 2010 5:20 AM, "Dag Sverre Seljebotn" <dagss(a)student.matnat.uio.no> wrote: Dan Roberts wrote: > Thanks for the reply. You're certainly right that your work is > extremely be... This might be relevant? http://conference.scipy.org/proceedings/SciPy2008/paper_16/ -- Dag Sverre _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy...

1 0

Re: [Numpy-discussion] My GSoC Proposal to Implement a Subset of NumPy for PyPy
by Dan Roberts 23 Apr '10

23 Apr '10

Thanks for the reply. You're certainly right that your work is extremely beneficial to mine. At present I'm afraid a great deal of NumPy C code isn't easily reusable and it's great you're addressing that. I may not have been thinking in line with Maciej, but I was thinking ufuncs would be written in pure Python and jit compiled to an efficient form. (We can make lots of nice assumptions about them) That said, I think being able to write generic ufuncs is a very good idea, and absolutely doable. On Apr 20, 2010 7:48 AM, "Travis Oliphant" <oliphant(a)enthought.com> wrote: On Apr 16, 2010, at 11:50 PM, Dan Roberts wrote: > Hello NumPy Users, > Hi everybody, my name i... Hi Daniel, This sounds like a great project, and I think it has promise. I would especially pay attention to the requests to make it easy to write ufuncs and generalized ufuncs in RPython. That has the most possibility of being immediately useful. Your timing is also very good. I am going to be spending some time re-factoring NumPy to separate out the CPython interface from the underlying algorithms. I think this re-factoring should help you in your long-term goals. If you have any input or suggestions while the refactoring is taking place, we are always open to suggestions and criticisms. Thanks for writing a NumPy-related proposal. Best regards, -Travis Thanks, Daniel Roberts > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discuss... -- Travis Oliphant Enthought Inc. 1-512-536-1057 http://www.enthought.com oliphant(a)enthought.com _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion(a)scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

3 2

wrapping arrays with savetxt
by Andreas 23 Apr '10

23 Apr '10

Hi there, I would like to use savetxt() to write a 2d array to a txt file. It should be written row-wise, but there should only be 10 values per line. So, if I want to write an array a((2,12)), the file should read like this: X X X X X X X X X X X X X X X X X X X X X X X X Is there any way to accomplish this? I thought I could iterate over the rows (with for), and use savetxt on each row individually. But then there's still the problem of wrapping. Since in the end the files are going to be pretty big (1440x2880), it would be good to do this as efficiently as possible ... Thanks for your insight, Andreas

1 0

[ANN] NumPy 1.4.1
by Ralf Gommers 22 Apr '10

22 Apr '10

Hi, I am pleased to announce the release of NumPy 1.4.1. This maintenance release removes datetime support, which fixes the binary incompatibility issues between NumPy 1.4.0 and SciPy and other extension packages. Several other bug fixes are also included. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ Thank you to everyone who contributed to this release; developers, users who reported bugs, documentation writers, etc... Enjoy! The NumPy developers

1 0

Is this a bug, and if so, who's?
by Ken Basye 22 Apr '10

22 Apr '10

Folks, Apologies for asking here, but I ran across this problem yesterday and probably need to file a bug. The problem is I don't know if this is a Numpy bug, a Python bug, or both. Here's an illustration, platform information follows. TIA, Ken ############################################# import collections import numpy as np class A (collections.namedtuple('ANT', ('x', 'y'))): def __float__(self): return self.y # Same as A, but explicitly convert y to a float in __float__() - this works around the assert fail class B (collections.namedtuple('BNT', ('x', 'y'))): def __float__(self): return float(self.y) a0 = A(1.0, 2.0) f0 = np.float64(a0) print f0 a1 = A(float(1.0), float(2.0)) f1 = np.float64(a1) print f1 b1 = B(np.float64(1.0), np.float64(2.0)) f2 = np.float64(b1) print f2 a2 = A(np.float64(1.0), np.float64(2.0)) # On some platforms, the next line will trigger an assert: # python: Objects/floatobject.c:1674: float_subtype_new: Assertion `((((PyObject*)(tmp))->ob_type) == &PyFloat_Type)' failed. f3 = np.float64(a2) print f3 ############################################# Platform info: Python 2.6.5 (r265:79063, Apr 14 2010, 13:32:56) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 >>> numpy.__version__ '1.3.0' ~--$ uname -srvmpio Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

2 1

Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2
by Ralf Gommers 21 Apr '10

21 Apr '10

Hi, I am pleased to announce the third release candidate of both Scipy 0.7.2 and NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy list. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ https://sourceforge.net/projects/scipy/files/ Changes from RC2 ============== SciPy: warnings about possible binary incompatibilities with numpy have been suppressed NumPy: - fixed compatibility with Python 2.7b1 - marked test for complex log as a known failure NumPy 1.4.1 ========== The main change over 1.4.0 is that datetime support has been removed. This fixes the binary incompatibility issues between NumPy and other libraries like SciPy and Matplotlib. There are also a number of other bug fixes, and no new features. Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. SciPy 0.7.2 ========= The only change compared to 0.7.1 is that the C sources for Cython code have been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will work with NumPy 1.4.1, while also retaining backwards compatibility with NumPy 1.3.0. Note that the 0.7.x branch was created in January 2009, so a lot of fixes and new functionality in current trunk is not present in this release. Binaries for Python 2.6 are available for both Windows and OS X. Due to the age of the code no binaries for Python 2.5 are available. On behalf of the NumPy and SciPy developers, Ralf

5 12