NumPy-Discussion July 2006

numpy-discussion@python.org

159 participants
223 discussions

Version numbers again
by Travis Oliphant 27 Jul '06

27 Jul '06

I'm still looking for ideas on version numbering. Right now, the trunk is at version 0.9.9 but this has bug-fixes from the 1.0b1 release. The next release will be 1.0b2 and should occur in about a week. I don't really like having the trunk use a 'lower' version number than the releases but I'm not sure what to do. The problem seems to stem from wanting to have the version number sort somewhat reasonably when the development number is tacked on. Will it work to have the trunk reflect the version number that was most recently released? In other words we could have the trunk be 1.0b1.<svn_version> So, a version number change doesn't happen until *after* the *next* release. Once 1.0b2 is tagged then the version number on the trunk changes to 1.0b2? When 1.0 comes out, then the trunk will be 1.0.<svn_version> A branch will then also be made with version number 1.0.0.<svn_version> when a 1.0.1 release is made the branch version number becomes 1.0.1.<svn_version> I don't think this solves all the version numbering issues someone is going to have if they use SVN-builds as a distribution, but perhaps it might give some sense of order to the system. -Travis

7 7

Re: [Numpy-discussion] Lightning talks [was:] Bug in memmap/python allocation code?
by Mike Ressler 27 Jul '06

27 Jul '06

On 7/26/06, Robert Kern <robert.kern(a)gmail.com> wrote: > > > > If someone can explain the rules of engagement for Lightning Talks, I'm > > thinking about presenting this at SciPy 2006. Then you'll see there is a > > reason for my madness. > > Unfortunately, we only have scheduled 30 minutes of lightning talks this > year. > We have twice as many full talks as we did last year. We'll probably only > get > about 5 or 6 lightning talks clocking in at 5 minutes, tops. In the > opening > remarks on the first day, we'll tell people to come talk to us (and by > "us," I > mean "Travis Vaught") during the break and tell us that they want to do a > lightning talk about "Foo." Okay - this will actually cause me some trouble as anything I might wish to present has to be cleared by our export compliance office in advance (I work at JPL). Travis V said he put me down on a list as interested, but I have to start the clearance process about now if I'm to do anything. What about posters? Have you thought about posters around the conference room for small presentations like mine that could just as easily described that way (as opposed to a talk)? Mike -- mike.ressler(a)alum.mit.edu

1 0

I've created a 1.0b1 release tag in SVN
by Travis Oliphant 26 Jul '06

26 Jul '06

I've created the 1.0b1 release tag in SVN and will be uploading files shortly to Sourceforge. I've also created a 1.0 release branch called ver1.0 The trunk is now version 1.1 of NumPy and should be used for new-development only. I don't expect 1.1 to come out for at least a year. Bug-fixes and small changes can happen on the 1.0 branch. These will be merged periodically to 1.1 or vice-versa. But, the 1.0 branch will be used for releases for the next year. AFAIK, this is similar to Python's release plan. I'm also going to be out of town for a few days and may not be able to check my email so you can ask questions, but I may not answer them for several days :-) Thanks to all you who helped with this release with bug reports and patches: Robert Kern David Cooke Pearu Peterson Alexander Belopolsky (Sasha) Albert Strasheim Stefan van der Walt Tim Hochberg Christopher Hanley Perry Greenfield Todd Miller David Huard Nils Wagner Thank you... I hope you all have a great weekend :-) Let's continue to make the beta release period productive by improving documentation and getting code-coverage tests and tracking down any bugs. Best regards, -Travis

6 7

Version numbers
by Travis Oliphant 26 Jul '06

26 Jul '06

I like the plan of adopting even-numbers for stable releases. So, if you have an odd-number then it is from the development trunk. Thus, after 1.1.SVN_number builds will come a stable 1.2 build Now, this doesn't solve the problem of what to do on the ver1.0 branch. I propose to do what Andrew suggested and change the version number on the ver1.0 branch to 0.9.9 until release 1.0 comes out. That way builds from the SVN tree will have the SVN version number attached to 0.9.9 and will be "smaller" than 1.0 Once 1.0 comes out then the development branch version number will be changed to 1.0.0 -Travis

1 0

Bug in memmap/python allocation code?
by Mike Ressler 26 Jul '06

26 Jul '06

My apologies if this is a duplicate - my first attempt doesn't seem to have gone back to the list. ---------- Forwarded message ---------- From: Mike Ressler <mike.ressler(a)alum.mit.edu> Date: Jul 25, 2006 12:17 PM Subject: Re: ***[Possible UCE]*** [Numpy-discussion] Bug in memmap/python allocation code? To: Travis Oliphant <oliphant.travis(a)ieee.org> Cc: Numpy-discussion(a)lists.sourceforge.net On 7/24/06, Travis Oliphant <oliphant.travis(a)ieee.org> wrote: > Mike Ressler wrote: > > I'm trying to work with memmaps on very large files, i.e. > 2 GB, up > > to 10 GB. Can't believe I'm really the first, but so be it. I just discovered the problem. All the places where > PyObject_As<Read/Write>Buffer is used needs to have the final argument > changed to Py_ssize_t (which in arrayobject.h is defined as int if you > are using less than Python 2.5). > > This should be fixed in SVN shortly.... Yeess! My little script can handle everything I've thrown at it now. It can read a 10 GB raw file, strip the top 16 bits, rearrange pixels, byte swap, and write it all back to a 5 GB file in 16 minutes flat. Not bad at all. And I've verified that the output is correct ... If someone can explain the rules of engagement for Lightning Talks, I'm thinking about presenting this at SciPy 2006. Then you'll see there is a reason for my madness. As an aside, the developer pages could use some polish on explaining the different svn areas, and how to get what one wants. An svn checkout as described on the page gets you the 1.1 branch that DOES NOT have the updated memmap fix. After a minute or two of exploring, I found that "svn co http://svn.scipy.org/svn/numpy/branches/ver1.0/numpy numpy" got me what I wanted. Thanks for your help and the quick solution. FWIW, I got my copy of the book a couple of weeks ago; very nice. Mike -- mike.ressler(a)alum.mit.edu -- mike.ressler(a)alum.mit.edu

2 1

Jason Fox Harun
by quotNo survey 26 Jul '06

26 Jul '06

days.A she chatted friendly bath people. against during bath Crash Camper tools UghSo allI family written boot blocks blesses system start concept ringing witching her. Weissman vital weapon home alike. poetry artwork deleting sections even contained damaged RAM. Once far virtually likely become also provides options should report Either version supported startup whatHim: Hoy at These tests executed manually repairs disks that program Los ON YOU CLICKI staggered said... sounds speeding overall ensures tells certainly have. pass restore full lazy View profile Posts Backing System Mums home. Being pretty disks. Version day week. also provides

1 0

lapack too small?
by Mathew Yeates 25 Jul '06

25 Jul '06

When I try and build I get the warning ********************************************************************* Lapack library (from ATLAS) is probably incomplete: size of /u/fuego0b/myeates/ATLAS/lib/SunOS_HAMMER32SSE3/liblapack.a is 318k (expected >4000k) Follow the instructions in the KNOWN PROBLEMS section of the file numpy/INSTALL.txt. ********************************************************************* But, there is no such file INSTALL.txt Whats wrong? This is on Solaris and I built the ATLAS libs myself. Mathew

2 1

how to get an array with "varying" poisson distribution
by Sebastian Haase 25 Jul '06

25 Jul '06

Hi, Essentially I'm looking for the equivalent of what was in numarray: from numarray import random_array random_array.poisson(arr) That is: if for example arr is a 256x256 array of positive integers, then this returns a new array of random numbers than are drawn according to the poisson statistics where arr's value at coordinate y,x determines the mean of the poisson distribution used to generate a new value for y,x. [[This is needed e.g. to simulate quantum noise in CCD images. Each pixel has different amount of noise depending of what it's (noise-free) "input" value was.]] Thanks, Sebastian Haase

5 6

cholesky regression in svn
by Sven Schreiber 25 Jul '06

25 Jul '06

Hi, I upgraded from 1.0b1 because I saw that the matrix-indexing bug was already fixed (thanks!). Now there's a new regression: >>> import numpy as n >>> n.__version__ '1.0.2891' >>> a = n.mat(n.eye(3)) >>> n.linalg.cholesky(a) array([[ 1., 0., 0.], [ 0., 1., 0.], [ 0., 0., 1.]]) This used to spit out a numpy-matrix, given the numpy-matrix input. -Sven

1 0

Best numpy code to learn from?
by Stephen Simmons 25 Jul '06

25 Jul '06

Hi, I've written some numpy functions for grouping, translating and subtotalling data. At the moment they exist as pure Python code, but I have started rewriting them in C for speed. As this is my first attempt at a C extension for numpy, I'd appreciate any suggestions for good numpy coding style to make this work for strided arrays, multiple data types, etc. My first go at a C version is very low level (following bincount()'s code in _compiled_base.c as a guide) and works for integer and character arrays. Are there other (possible more recent) numpy source files that I should use as a guide to writing fast, clean, flexible code? Cheers Stephen

2 1

← Newer
1
2
3
4
5
6
7
...
23
Older →

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion July 2006