Re: [Numpy-discussion] fixing diag() for matrices

[Robert Kern]

Sven Schreiber wrote:
> That would be fine with me. However, I'd like to point out that after
> some bug-squashing currently all numpy functions deal with
> numpy-matrices correctly, afaik. The current behavior of numpy.diag
> could be viewed as a violation of that principle. (Because if x has
> shape (n,1), diag(x) returns only the first entry, which is pretty
> stupid for a diag-function operating on a vector.)

I don't think so. It's operating exactly as it is documented to. It doesn't do 
what you want, but it's not supposed to read your mind and guess that you are 
treating (n,1) and (1,n) arrays as linear algebraic vectors and that you want 
to 
form a diagonal matrix from that vector. It handles matrix objects just fine; 
it 
does not obey a particular convention that you want to use, though. That's 
neither broken nor a violation of the principle that most numpy functions 
should 
accept matrix objects; it's just not what you want.

I don't want to introduce a backwards-compatibility-breaking special case to 
the 
function. "Special cases aren't special enough to break the rules." Different 
functionality should go into a different function.

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Version numbers again

[Albert Strasheim]

Hello all

Another +1. When I build a Windows installer, I get:

numpy-1.0b2.dev2915.win32-py2.4.exe

This tells me everything I want to know.

Regards,

Albert

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:numpy-
> [EMAIL PROTECTED] On Behalf Of Sasha
> Sent: 27 July 2006 21:26
> To: Andrew Straw
> Cc: Travis Oliphant; numpy-discussion
> Subject: Re: [Numpy-discussion] Version numbers again
> 
> On 7/27/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> [snip]
> > The one system that I
> > suggest we really try to work with out-of-the-box, however, is
> > setuptools, which, luckily, attached special meaning to ".dev" in a
> > release number, so that it sorts _before_ the release. (In setuptools
> > jargon, ".dev" is a pre-release tag. See
> > http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-
> project-s-version
> > for more info.) In other words, with setuptools, 1.0b2.dev-r2891 sorts
> > after 1.0b1 and pre 1.0b2. If nothing else, this maintains greatest
> > consistency with what the current system, merely adding the ".dev-r"
> > prefix before the svn revision.
> 
> +1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Version numbers again

[Sasha]

On 7/27/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
[snip]
> The one system that I
> suggest we really try to work with out-of-the-box, however, is
> setuptools, which, luckily, attached special meaning to ".dev" in a
> release number, so that it sorts _before_ the release. (In setuptools
> jargon, ".dev" is a pre-release tag. See
> http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
> for more info.) In other words, with setuptools, 1.0b2.dev-r2891 sorts
> after 1.0b1 and pre 1.0b2. If nothing else, this maintains greatest
> consistency with what the current system, merely adding the ".dev-r"
> prefix before the svn revision.

+1

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Version numbers again

[Andrew Straw]

Travis Oliphant wrote:
> 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.
>   
Sasha is correct that most users of these version numbers can override
the version numbers that come direct from numpy. The one system that I
suggest we really try to work with out-of-the-box, however, is
setuptools, which, luckily, attached special meaning to ".dev" in a
release number, so that it sorts _before_ the release. (In setuptools
jargon, ".dev" is a pre-release tag. See
http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
for more info.) In other words, with setuptools, 1.0b2.dev-r2891 sorts
after 1.0b1 and pre 1.0b2. If nothing else, this maintains greatest
consistency with what the current system, merely adding the ".dev-r"
prefix before the svn revision.

I suggest a special attempt to work with setuptools out of the box
because it's partner-in-crime, easy-install, is able to automatically
find, download and build from releases or svn development versions, and
it would be great to let our users use this standard machinery if they
like. And we'll get calls for help if it doesn't. We can expect
packagers from Debian and elsewhere to do the right thing, however, so
we shouldn't worry overly about them.

Here is a clipping from a recent session with setuptools'
pkg_resources.parse_version() function, which returns sortable tuple:

In [15]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.dev-r2891') < 
pkg_resources.parse_version('1.0b2')
Out[15]: True

In [16]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2dev-r2891') < 
pkg_resources.parse_version('1.0b2')
Out[16]: True

In [17]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.2891') < 
pkg_resources.parse_version('1.0b2')
Out[17]: False

In [18]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.dev2891') < 
pkg_resources.parse_version('1.0b2')
Out[18]: True

In [19]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2-dev2891') < 
pkg_resources.parse_version('1.0b2')
Out[19]: True

So, basically, setuptools could handle any of these cases except what
we've currently got. Admittedly, these schemes depend on setuptools'
special handling of "dev" as a pre-release tag, but at least it's very
nearly consistent with our current situation.

On the other hand, we could try and work even with systems that don't
have special pre-release tags. I think the system you propose below
would work for this with one caveat.

> 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.
>
> 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.
>
> A branch will then also be made with version number
>
> 1.0.0.
>
> when a 1.0.1 release is made the branch version number becomes
>
> 1.0.1.
>
>   
The caveat is that sorting across branches, as you point out, is
difficult. (Although I must say that this seems like a difficult thing
to get "right", considering that the whole point of branches is to have
two versions simultantously current.)

But, in your proposal above, most (or all) sane version sorting systems
would at least sort both numpy releases and numpy svn versions into
their actual order. Which is all I was asking for, but maybe the cost
for breaking with out versioning tradition is too much, as some people
suggest.
> 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.
Thanks for taking this issue seriously. On the one hand, it's ridiculous
to spend our times worrying about version numbers, but on the other
hand, we should be able to interact with automated tools whose purpose
is to make life easier (in the long term, anyway!).

Cheers,
Andrew

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.

Re: [Numpy-discussion] Version numbers again

[Fernando Perez]

On 7/27/06, Francesc Altet <[EMAIL PROTECTED]> wrote:
> Travis,

> Speaking on what we regularly do, I would choose a 1.0b2. for the
> trunk version. This is a way to say people: "Hey, you are using a version
> that will be the 1.0b2 in the future.".  Of course, the same meaning can be
> achieved if you interpret that a X.Y.Z. means something like
> post-X.Y.Z. I think all depends on interpretation. I personally prefer the
> first option (i.e. start using a future release number in SVN), rather than
> the second (i.e. using a past release version in SVN) because I tend to find
> it slightly less confusing.

Just  as a reference, that's also what I do with ipython:

planck[homepage]> ip
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.3.svn -- An enhanced Interactive Python.

This means  'what will be 0.7.3, currently from svn'.  I don't
actually tack the revision number, only the 'svn' indicator, but it's
the same idea.   Since ipython's dev pace is slower, I don't worry so
much about individual numbers, but this lets me know easily if someone
is reporting a bug from running off SVN or an official release.

Cheers,

f

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] weave and Numeric vs. weave and numpy

[David Grant]

A factor of 2! Is that short for a factor of **2?On 7/27/06, Rolf Wester <[EMAIL PROTECTED]
> wrote:Hello,I have a program using Numeric and weave developed with 
Python2.3. Ijust switched to Python2.4 and numpy. The Numeric/weave version isalmost a factor of 2 faster compared to numpy/weave. Is that what is tobe expected or are there options to improve the speed of numpy/weave? I
would be very appreciative for any help. Please find the source attached.RegardsRolf--# Dr. Rolf Wester# Fraunhofer Institut f. Lasertechnik
# Steinbachstrasse 15, D-52074 Aachen, Germany.# Tel: + 49 (0) 241 8906 401, Fax: +49 (0) 241 8906 121# EMail: [EMAIL PROTECTED]# WWW:   
http://www.ilt.fraunhofer.de-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___Numpy-discussion mailing listNumpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion-- David Grant
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] weave and Numeric vs. weave and numpy

[Rolf Wester]

Hello,

I have a program using Numeric and weave developed with Python2.3. I 
just switched to Python2.4 and numpy. The Numeric/weave version is 
almost a factor of 2 faster compared to numpy/weave. Is that what is to 
be expected or are there options to improve the speed of numpy/weave? I 
would be very appreciative for any help. Please find the source attached.


Regards

Rolf


--

# Dr. Rolf Wester
# Fraunhofer Institut f. Lasertechnik
# Steinbachstrasse 15, D-52074 Aachen, Germany.
# Tel: + 49 (0) 241 8906 401, Fax: +49 (0) 241 8906 121
# EMail: [EMAIL PROTECTED]
# WWW:   http://www.ilt.fraunhofer.de
import math
import sys
if sys.version[0:3] == '2.3':
	from Numeric import *
	import weave
else:
	from  numpy import *
	import scipy.weave as weave
	Float64 = float64
	Complex64 = complex128

cc   = 2.997924e14 # mum/s
mu0  = 1.256637e-12 # Vs/(A mum)
eps0 = 1.0/(mu0*cc**2) # As/(V mum)
Z0   = sqrt(mu0/eps0)
pi   = math.pi

def make_spaces(n):
	s = ""
	for i in range(n):
		s = s + ' '
	return s

def split2(str, sep = ' \t\n\r', trimp = 'yes'):
	vstr = []
	n0   = len(str)
	n= len(sep)
	
	ipos0 = 0
	ipos1 = 0

	while ipos1 < n0 and ipos0 < n0:
		ipos0 = ipos1
		flag  = 0
		c2= str[ipos0]
		for i in range(n):
			if(c2 == sep[i]):
flag = 1
break
			
		while(flag == 1):
			ipos0 = ipos0+1
			if(ipos0 > n0-1): 
break
			flag = 0
			c2 = str[ipos0]
			for i in range(n):
if(c2 == sep[i]):
	flag = 1
	break
			
			if(ipos0 > n0-1):
break
			ipos1 = ipos0
			flag  = 0
			c2= str[ipos1]
			for i in range(n):
if c2 == sep[i]:
	flag = 1
	break

		while flag == 0:
			ipos1 = ipos1+1
			if ipos1 > n0-1: 
break
			flag = 0
			c2 = str[ipos1]
			for i in range(n):
if c2 == sep[i]:
	flag = 1
	break
		if(ipos0 < ipos1):
			teil = str[ipos0:ipos1]
			if(trimp == 'yes'):
teil = string.strip(teil)
			vstr.append(teil)

	return vstr


class LSSOLV:
	def __init__(self, N):
		self.N = N
		self.gamma = zeros(N, Complex64)
		self.betai = zeros(N, Complex64)

	def inline_solve(self, a, b, c, d, y):
		betai = self.betai
		gamma = self.gamma
		N = self.N
		
		code = """
		int i;
		betai[0] = 1.0/b[0];


		for(i=1; i < N; i++)
			betai[i] = 1.0/(b[i]-a[i]*c[i-1]*betai[i-1]);
	
		gamma[0] = d[0]*betai[0];
		for(i=1; i < N; i++)
			gamma[i] = (d[i]-a[i]*gamma[i-1])*betai[i];

		y[N-1] = gamma[N-1];
		for(i=N-2; i >= 0; i--)
			y[i] = gamma[i]-c[i]*y[i+1]*betai[i];

	return_val = y[300];
		"""
		err = weave.inline(code,
   ['a', 'b', 'c', 'd', 'betai', 'gamma', 'y', 'N'],
   #type_converters = weave.converters.blitz,
   compiler = 'gcc',verbose=2)
		return err

	def blitz_solve(self, a, b, c, d, y):
		betai = self.betai
		gamma = self.gamma
		N = self.N
		
		code = """
		int i;
		betai(0) = 1.0/b(0);

		for(i=1; i < N; i++)
			betai(i) = 1.0/(b(i)-a(i)*c(i-1)*betai(i-1));
	
		gamma(0) = d(0)*betai(0);
		for(i=1; i < N; i++)
			gamma(i) = (d(i)-a(i)*gamma(i-1))*betai(i);

		y(N-1) = gamma(N-1);
		for(i=N-2; i >= 0; i--)
			y(i) = gamma(i)-c(i)*y(i+1)*betai(i);

	return_val = y(300);
		"""
		err = weave.inline(code,
   ['a', 'b', 'c', 'd', 'betai', 'gamma', 'y', 'N'],
   type_converters = weave.converters.blitz,
   compiler = 'gcc')
		return err

	def solve(self, a, b, c, d, y):
		
		betai = self.betai
		gamma = self.gamma
		N = self.N

		betai[0] = 1.0/b[0]

		for i in range(1,N):
			betai[i] = 1.0/(b[i]-a[i]*c[i-1]*betai[i-1])
	
		gamma[0] = d[0]*betai[0]
		for i in range(1,N):
			gamma[i] = (d[i]-a[i]*gamma[i-1])*betai[i]

		y[self.N-1] = gamma[N-1]	
		for i in range(N-2,-1,-1):
			y[i] = gamma[i]-c[i]*y[i+1]*betai[i]

	

class Parameter:
	def __init__(self, filename):
		self.map = {}
		
		ein = file(filename, 'r')
		inhalt = ein.readlines()
		head = ''
		for line in inhalt:
			line = split2(line,sep = '=#', trimp = 'yes')
			if len(line) > 0 and len(line[0]) > 0 and line[0][0] == '[' and line[0][len(line[0])-1] == ']':
head = line[0][1:len(line[0])-1]
			if len(line) >= 2:
self.map[head + '.' + line[0]] = line[1]

			
	def get(self, key, val):
		ret = val
		if self.map.has_key(key):
			if type(val) == type(1.0):
ret = float(self.map[key])
			elif type(val) == type(1):
ret = int(self.map[key])
			else:
ret = self.map[key]
		return ret

	
	def set(self, key, val):
		if type(val) == type(1.0):
			self.map[key] = "%e" % val
		elif type(val) == type(1):
			self.map[key] = "%i" % val
		else:
			self.map[key] = val

	def print_parameter(self, out = None):
		list = []
		for key in self.map:
			list.append([key, self.map[key]])
		list.sort()
			
		lmax = 0
		for key in self.map:
			n = len(key)
			if (n > lmax):
lmax = n

		ausgabe = " parameter begin \n"
		for l in list:
			n   = len(l[0])
			spaces  = make_spaces(lmax+2-n)
			ausgabe = au

Re: [Numpy-discussion] Version numbers again

[Christopher Barker]

Travis Oliphant wrote:
> When 1.0 comes out, then the trunk will be
> 
> 1.0.

Shouldn't the trunk then become:

1.1.0. or 1.1

That would signify a development version, which I understand is what the 
trunk would then be. And it would be a greater version than the released 
one, which is what we'd want.

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Version numbers again

[Francesc Altet]

Travis,

A Dijous 27 Juliol 2006 18:22, Travis Oliphant va escriure:
> 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.

Speaking on what we regularly do, I would choose a 1.0b2. for the 
trunk version. This is a way to say people: "Hey, you are using a version 
that will be the 1.0b2 in the future.".  Of course, the same meaning can be 
achieved if you interpret that a X.Y.Z. means something like 
post-X.Y.Z. I think all depends on interpretation. I personally prefer the 
first option (i.e. start using a future release number in SVN), rather than 
the second (i.e. using a past release version in SVN) because I tend to find 
it slightly less confusing.

However, I think that if you choose whatever convention consistently, people 
will get used to it and everything will be fine.

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Version numbers again

[Sasha]

On 7/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
[snip]
> 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.
>
Don't fix it if it ain't broken.  Applications that need sortable
version numbers can work out their own convention.  For example,
1.0.0., 1.0.0.final, 1.0.1..  Numpy was following a
consistent and convenient rule for a long time, changing that now will
only lead to confusion.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Version numbers again

[Travis Oliphant]

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.

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.

A branch will then also be made with version number

1.0.0.

when a 1.0.1 release is made the branch version number becomes

1.0.1.


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




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] possible bug in seed argument

[Robert Kern]

Gary Ruben wrote:
> Should
>  >>> seed(1)
> act the same as
>  >>> seed(array([1]))
> in the random module?

No. They use slightly different mechanisms to seed. The integer uses 
RandomKit's 
seeding routine. I borrowed Python's mechanism for seeding from an array of 
integers. Now that it comes up, though, it is probably a good idea to use the 
same mechanism for both cases.

> It generates a traceback with the Windows 1.0b1 binary.

Please always copy-and-paste tracebacks when reporting bugs. It works for me 
with r2881; I'll rebuild with a later version and try again.

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Lightning talks [was:] Bug in memmap/python allocation code?

[Mike Ressler]

On 7/26/06, Robert Kern <[EMAIL PROTECTED]> 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 getabout 5 or 6 lightning talks clocking in at 5 minutes, tops. In the openingremarks 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 alightning 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
-- [EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Robert Kern]

David M. Cooke wrote:
> That's one reason that I'm careful (or least try to be) in my change messages
> to mention the ticket number for the bug fixed in the first line, so that
> Trac will show it in the source browser, and to mention the revision number
> of the fix in the ticket itself. The comment for stuff merged from one branch
> to the other mentions which revisions are being merged from the original
> branch (again, on the first line so Trac will see it). If applicable, add the
> merge to the ticket also.
> 
> Merging a bug fix between trunks as soon as possible is a good idea too!
> 
> Then it's a relatively simple matter to browse through Trac and see what's
> been merged, and what commits fix which.

The problem is that it's still a lot of work keeping two branches in sync with 
each other over long periods of time. Until 1.0 final goes out, everything 
getting checked into the 1.0 branch should also be on the trunk. Once 1.0 final 
is out and the 1.0.x maintenance series begins, that's the time to branch since 
the branch is then intended to be different from the trunk.

My experience with long-lived branches is quite bad. They've caused me a lot of 
problems at work.

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Travis Oliphant]

Robert Kern wrote:
> Let's not make a branch until 1.0 is actually out and we are making 1.0.x 
> releases. It's confusing since at the moment, the trunk is not getting any 
> activity. It's not the main trunk of development. Some people have already 
> come 
> to the list confused about where to get the code with fixes to the bugs 
> they've 
> reported. The branches are getting too far diverged at the moment. It's going 
> to 
> be hell merging them, and we are going to lose the revision history when we 
> do 
> merge. The revision messages won't be joined with the the changes they talk 
> about.
>   

This is sound reasoning.  I was way too pre-mature in making a ver1.0 
branch.  I had thought that backward incompatible changes would go into 
the trunk and the ver1.0 branch would be more or less stable.  But this 
was not a wise move as I'm beginning to see.   If somebody wants to 
experiment with a change, they can make a branch...

The trunk should be the main line of development.   I apologize for my 
stumbling over these software-release issues.  I'm really not a 
software-manager at heart --- do we have any volunteers for a 
release-manager :-)

I'm going to re-number the trunk to 0.9.9. 

I'm also going to delete the ver1.0 branch and chalk that up to a 
learning mistake.

We will make a 1.0 branch for building maintenance releases from as soon 
as 1.0 comes out officially which won't be for a few months --- Let's 
target the first of October, for now.


-Travis


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Bug in memmap/python allocation code?

[Robert Kern]

Mike Ressler wrote:
> My apologies if this is a duplicate - my first attempt doesn't seem to 
> have gone back to the list.

SF if being nasty with GMail. I'll have to speed up moving the list to 
scipy.org.

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

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

Grr. That means developers are not merging changes appropriately.

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] uniform() regression(?) in svn

[Robert Kern]

Andrew Jaffe wrote:
> Hi-
> 
> On PPC Mac OSX universal build 2.4.3, gcc 4.0,
> 
> 
> In [1]: import numpy as N
> 
> In [2]: print N.__version__
> 1.0.2897
> 
> In [3]: N.random.uniform(0,1)
> Segmentation fault

Travis recently (r2892) checked in a pretty major change to the distributions 
to 
allow them to broadcast over their arguments. That's probably the source of the 
regression.

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] possible bug in seed argument

[Gary Ruben]

Should
 >>> seed(1)
act the same as
 >>> seed(array([1]))
in the random module?
It generates a traceback with the Windows 1.0b1 binary.

Gary R.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion