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
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
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
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
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
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
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
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
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
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
