numpy-discussion — Discussion list for all users of Numerical Python

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

[Keith G. <kwg...@gm...>]

Every time I want to make a diagonal matrix from a vector I have to do
a google search. So I'm with you Sven:

diag(NxN matrix) should return a Nx1 matrix
diag(Nx1 or 1xN matrix) should return a NxN matrix

instead of the current behavior:

diag(NxN matrix) returns an array
diag(Nx1 matrix) returns a 1x1 array

>> x

matrix([[ 0.43298158,  0.84572719],
        [ 0.1391546 ,  0.66412104]])
>> diag(x)
   array([ 0.43298158,  0.66412104])
>> diag(x[:,0])
   array([ 0.43298158])



On 7/28/06, Sven Schreiber <sve...@gm...> wrote:
> Robert Kern schrieb:
> > 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.
>
> Ok, let me get some facts straight:
>
> 1. If you're using numpy-matrices, algebraic vectors are *automatically*
> (n,1) or (1,n). I didn't make it up, and nobody has to read my mind to
> understand that; it's just a *fact* of numpy (and you knew that long
> before I was even aware of numpy's existence ;-).
>
> 2. I never claimed that the documentation of diag is wrong. I'm just
> questioning whether its behavior with vectors represented as
> numpy-matrices (which have shape (n,1) or (1,n) and are therefore always
> 2d in the numpy sense) is really intended, because I currently doubt
> that it's useful for *anyone*. (Of course you can prove me wrong there...)
>
> 3. The cited principle is not (only) about accepting matrices, it's
> about "honoring" them by either preserving their type for the output,
> and of course by doing the equivalent thing as for the equivalent
> numpy-array input. Currently, however, diag() is not providing the
> "vector-to-diagonal-matrix" functionality if you work with
> numpy-matrices (modulo some obvious workarounds). To me, that's a partly
> broken function, and it's *not* handling matrix objects "just fine".
>
>
> >
> > 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.
> >
>
> I hope (but somehow doubt...) that I've convinced you that it's actually
> about applying the same logical rule to all input types, not about
> introducing a special case. I agree that in principle backwards
> compatibility could be an issue; however that would mean that people are
> actually using the strange behavior that diag() displays with (n,1) or
> (1,n) matrix-vectors (namely returning only the first element).
>
> Does anybody do that? I doubt it, but of course I can't prove it; does
> anybody on the list know of an example where it's used?
>
> Having said all that in this lengthy message, I don't want to push it
> too far. I believe that the right thing to do would be to fix diag()
> along the lines I suggested. If I haven't managed to convince you and/or
> the other developers, so be it, and I can live with a new
> numpy.matlib.diag() just fine.
>
> In the latter case, may I also suggest that a new numpy.matlib.diag()
> always return a numpy-matrix even when given a numpy-array? Background:
> Currently (and I think it's ok that way) the eig*() functions return the
> eigenvalues in a 1d-array, even for numpy-matrices as inputs. It is
> fairly usual to use a diagonal matrix with the eigenvalues on the
> diagonal in an algebraic formula. That could be achieved with
> n.matlib.diag(n.linalg.eig*(...)[0]) without an enclosing mat() call
> only if n.matlib.diag always returns a numpy-matrix.
>
> Thanks for reading until the end...
> cheers,
> Sven
>
>
> -------------------------------------------------------------------------
> 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
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

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

[Sven S. <sve...@gm...>]

Robert Kern schrieb:
> 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.

Ok, let me get some facts straight:

1. If you're using numpy-matrices, algebraic vectors are *automatically*
(n,1) or (1,n). I didn't make it up, and nobody has to read my mind to
understand that; it's just a *fact* of numpy (and you knew that long
before I was even aware of numpy's existence ;-).

2. I never claimed that the documentation of diag is wrong. I'm just
questioning whether its behavior with vectors represented as
numpy-matrices (which have shape (n,1) or (1,n) and are therefore always
2d in the numpy sense) is really intended, because I currently doubt
that it's useful for *anyone*. (Of course you can prove me wrong there...)

3. The cited principle is not (only) about accepting matrices, it's
about "honoring" them by either preserving their type for the output,
and of course by doing the equivalent thing as for the equivalent
numpy-array input. Currently, however, diag() is not providing the
"vector-to-diagonal-matrix" functionality if you work with
numpy-matrices (modulo some obvious workarounds). To me, that's a partly
broken function, and it's *not* handling matrix objects "just fine".


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

I hope (but somehow doubt...) that I've convinced you that it's actually
about applying the same logical rule to all input types, not about
introducing a special case. I agree that in principle backwards
compatibility could be an issue; however that would mean that people are
actually using the strange behavior that diag() displays with (n,1) or
(1,n) matrix-vectors (namely returning only the first element).

Does anybody do that? I doubt it, but of course I can't prove it; does
anybody on the list know of an example where it's used?

Having said all that in this lengthy message, I don't want to push it
too far. I believe that the right thing to do would be to fix diag()
along the lines I suggested. If I haven't managed to convince you and/or
the other developers, so be it, and I can live with a new
numpy.matlib.diag() just fine.

In the latter case, may I also suggest that a new numpy.matlib.diag()
always return a numpy-matrix even when given a numpy-array? Background:
Currently (and I think it's ok that way) the eig*() functions return the
eigenvalues in a 1d-array, even for numpy-matrices as inputs. It is
fairly usual to use a diagonal matrix with the eigenvalues on the
diagonal in an algebraic formula. That could be achieved with
n.matlib.diag(n.linalg.eig*(...)[0]) without an enclosing mat() call
only if n.matlib.diag always returns a numpy-matrix.

Thanks for reading until the end...
cheers,
Sven

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

[Rolf W. <rol...@il...>]

David Grant wrote:
> A factor of 2! Is that short for a factor of **2?
> 
That means Numeric/weave takes about 17 s (on my PC), and the 
numby/weave version takes about 32 s.


-- 
------------------------------------
# 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: rol...@il...
# WWW:   http://www.ilt.fraunhofer.de

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

[Robert K. <rob...@gm...>]

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

Re: [Numpy-discussion] Version numbers again

[Albert S. <fu...@gm...>]

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: num...@li... [mailto:numpy-
> dis...@li...] 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 <str...@as...> 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

Re: [Numpy-discussion] Version numbers again

[Sasha <nd...@ma...>]

On 7/27/06, Andrew Straw <str...@as...> 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

Re: [Numpy-discussion] Version numbers again

[Andrew S. <str...@as...>]

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

Re: [Numpy-discussion] Version numbers again

[Fernando P. <fpe...@gm...>]

On 7/27/06, Francesc Altet <fa...@ca...> wrote:
> Travis,

> Speaking on what we regularly do, I would choose a 1.0b2.<svn_version> 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.<svn_version> 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

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

[David G. <dav...@gm...>]

A factor of 2! Is that short for a factor of **2?

On 7/27/06, Rolf Wester <rol...@il...> wrote:
>
> 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: rol...@il...
> # WWW:   http://www.ilt.fraunhofer.de
>
>
> -------------------------------------------------------------------------
> 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
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>
>


-- 
David Grant

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

[Rolf W. <rol...@il...>]

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: rol...@il...
# WWW:   http://www.ilt.fraunhofer.de

Re: [Numpy-discussion] Version numbers again

[Christopher B. <Chr...@no...>]

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

Shouldn't the trunk then become:

1.1.0.<svn_version> or 1.1<svn_version>

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

Chr...@no...

Re: [Numpy-discussion] Version numbers again

[Francesc A. <fa...@ca...>]

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

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

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

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Version numbers again

[Sasha <nd...@ma...>]

On 7/27/06, Travis Oliphant <oli...@ee...> 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.<svn rev>, 1.0.0.final, 1.0.1.<svn rev>.  Numpy was following a
consistent and convenient rule for a long time, changing that now will
only lead to confusion.

[Numpy-discussion] Version numbers again

[Travis O. <oli...@ee...>]

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

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

[Robert K. <rob...@gm...>]

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

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

[Mike R. <mik...@gm...>]

On 7/26/06, Robert Kern <rob...@gm...> 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

-- 
mik...@al...

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

[Robert K. <rob...@gm...>]

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

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

[Travis O. <oli...@ie...>]

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

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

[Robert K. <rob...@gm...>]

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

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

[Robert K. <rob...@gm...>]

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

[Numpy-discussion] possible bug in seed argument

[Gary R. <gr...@bi...>]

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.

[Numpy-discussion] Version numbers

[Travis O. <oli...@ie...>]

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

Re: [Numpy-discussion] Profiling line-by-line

[David G. <dav...@gm...>]

Does anyone know if this issue related to profiling with numpy is a python
problem or a numpy problem?

Dave

On 7/20/06, David Grant <dav...@gm...> wrote:
>
>
>
> On 7/20/06, Arnd Baecker <arn...@we...> wrote:
> >
> >
> > More importantly note that profiling in connection
> > with ufuncs  seems problematic:
>
>
> Yes, that seems to be my problem...  I read the threads you provided links
> to. Do you know why this is the case?
>
> I have tried hotshot2calltree by the way, and I didn't find out anything
> new.
>
> --
> David Grant
>



-- 
David Grant

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

[David M. C. <co...@ph...>]

On Wed, 26 Jul 2006 11:14:42 -0500
Robert Kern <rob...@gm...> wrote:

> Travis Oliphant wrote:
> > 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.
> 
> 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.

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.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

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

[Robert K. <rob...@gm...>]

Travis Oliphant wrote:
> 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.

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.

In point of example, Python development for a 2.x version goes on the trunk 
until the actual release of 2.x. Then a 2.x branch is created for maintainings 
2.x.y and the trunk develops for 2.x+1. We aren't going to be working on 1.1 
until 1.0 is actually out the door.

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