Hi all,
You probably remember that I said that after numpy 1.7.0 was out I wanted
to step down as release manager for NumPy and focus more on SciPy. That was
4.5 months ago, and now that 1.7.0 keeps being postponed I'm actually
planning to not wait for it. I have found that it's not possible for m
On Sat, Feb 6, 2010 at 6:44 PM, René Dudfield wrote:
> Hi,
>
> may I suggest an addition to the release process...
>
> 'Tests against popular libraries that rely on numpy at the RC stage.
> Test at least these libraries pass their numpy related tests:
> matplotlib, scipy, pygame, (insert others h
Hi,
may I suggest an addition to the release process...
'Tests against popular libraries that rely on numpy at the RC stage.
Test at least these libraries pass their numpy related tests:
matplotlib, scipy, pygame, (insert others here?). The release manage
should ask the mailing list for people t
Thanks Chuck,
I didn't know there were other tests for histogram outside of
test_function_base.
The error is now raised only if bins are passed explicitly and normed=True.
David
2008/4/25 Charles R Harris <[EMAIL PROTECTED]>:
>
>
> On Fri, Apr 25, 2008 at 12:55 PM, Jarrod Millman <[EMAIL PROTE
On Fri, Apr 25, 2008 at 12:55 PM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Fri, Apr 25, 2008 at 12:55 PM, David Huard <[EMAIL PROTECTED]>
> wrote:
> > > Done in r5085. I added a bunch of tests, but I'd appreciate if someone
> > could double check before the release. This is not the time to i
On Fri, Apr 25, 2008 at 12:55 PM, David Huard <[EMAIL PROTECTED]> wrote:
> > Done in r5085. I added a bunch of tests, but I'd appreciate if someone
> could double check before the release. This is not the time to introduce new
> bugs.
> >
> > Hopefully this is the end of the histogram saga.
> >
>
>
2008/4/25 David Huard <[EMAIL PROTECTED]>:
> 2008/4/24 Jarrod Millman <[EMAIL PROTECTED]>:
>
> > On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote:
> > > Assuming we want the next version to : ignore values outside of range
> > and
> > > accept and return the bin edges instead of the left edges,
2008/4/24 Jarrod Millman <[EMAIL PROTECTED]>:
> On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote:
> > Assuming we want the next version to : ignore values outside of range
> and
> > accept and return the bin edges instead of the left edges, here could be
> the
> > new signature for 1.1:
> > h,
2008/4/25 Stéfan van der Walt <[EMAIL PROTECTED]>:
> I'm starting to see Chris Barker's point; allowing x[0] is causing
> more problems than it is worth. On the other hand, how would you
> index into a vector (as in
> http://en.wikipedia.org/wiki/Vector_(spatial)) without it?
To answer my own
2008/4/25 Anne Archibald <[EMAIL PROTECTED]>:
> > The agreement was:
Clearly that was only the agreement in my mind. I apologise if I
jumped the gun.
> > a) That x[0][0] should be equal to x[0,0] and
> > b) That x[0,:] should be equal to x[0] (as for ndarrays)
> >
> > This breaks as litt
I was hoping to get NumPy 1.1 tagged today, but it seems very unlikely
at this point. Unfortunately, I haven't followed the matrix
discussion as closely as I would like, so I can't tell if there is
anything so uncontroversial that it would make sense to change for the
1.1.0 release. If there is s
Anne Archibald wrote:
> Yes, well, it really looks unlikely we will be able to agree on what
> the correct solution is before 1.1, so I would like to have something
> non-broken for that release.
>
+1 on that!
___
Numpy-discussion mailing list
Numpy-d
On Fri, Apr 25, 2008 at 10:04 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> I think the use of the term 'vector' in this
> thread is becoming a bit confusing.
>
> An M by N matrix is a vector. (I.e., it is
> an element of a vector space.)
>
Sure, but the important thing is the multiplication. If
On 25/04/2008, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> 2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
>
> > I must have misunderstood:
> > I thought the agreement was to
> > provisionally return a 1d array for x[0],
> > while we hashed through the other proposals.
>
> The agreement was
2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
> I must have misunderstood:
> I thought the agreement was to
> provisionally return a 1d array for x[0],
> while we hashed through the other proposals.
The agreement was:
a) That x[0][0] should be equal to x[0,0] and
b) That x[0,:] should be equal
On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> In current SVN:
> In [6]: x[0]
> Out[6]: matrix([[0, 1, 2]])
I must have misunderstood:
I thought the agreement was to
provisionally return a 1d array for x[0],
while we hashed through the other proposals.
Cheers,
Alan
___
I think the use of the term 'vector' in this
thread is becoming a bit confusing.
An M by N matrix is a vector. (I.e., it is
an element of a vector space.)
Many people use the terms "row vector" and "column
vector" to refer to special matrices. What is
special is *not* that they are vectors (sin
2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
> > 2008/4/25 Alan G Isaac :
>
> >> So, if X is 2 by 2, then X[0] will be a row vector.
> >> But if X is 1 by 2, then X[0] will be a scalar?
> >> Ouch!
> >> Bye bye generic code.
>
>
> On Fri, 25 Apr 2008, Stefan van der Walt apparently wrote:
> >
Christopher Barker wrote:
[cjop]
>
> Bruce Southey wrote:
>
>> Hi,
>> I would like to use the matrix functionality but I, like others, get by
>> without it.
>>
>
> What does it lack that keeps you from using it? That's the key question?
>
I mainly do matrix-matrix and matrix-vector mult
> 2008/4/25 Alan G Isaac :
>> So, if X is 2 by 2, then X[0] will be a row vector.
>> But if X is 1 by 2, then X[0] will be a scalar?
>> Ouch!
>> Bye bye generic code.
On Fri, 25 Apr 2008, Stefan van der Walt apparently wrote:
> Yup. That's the current state of things.
I do not understand.
T
On Fri, Apr 25, 2008 at 10:23 AM, Christopher Barker
<[EMAIL PROTECTED]> wrote:
> Alan G Isaac wrote:
> > On Thu, 24 Apr 2008, Christopher Barker apparently wrote:
> >> I suppose a "Vector" can be either a (n,1) or a (1,n)
> >> matrix that allows single indexing.
> >
> > This bothers me.
> >
Alan G Isaac wrote:
> On Thu, 24 Apr 2008, Christopher Barker apparently wrote:
>> I suppose a "Vector" can be either a (n,1) or a (1,n)
>> matrix that allows single indexing.
>
> This bothers me.
>
> So, if X is 2 by 2, then X[0] will be a row vector.
> But if X is 1 by 2, then X[0] will be a
On Thu, Apr 24, 2008 at 11:16 AM, Timothy Hochberg
<[EMAIL PROTECTED]> wrote:
>
> [CHOP]
>
> The proposals thus far don't address two of the major issues I have with the
> matrix class:
The thing that seems missing to me is support for LAPACK's banded and
packed (triangular) storage formats. I do
2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
> So, if X is 2 by 2, then X[0] will be a row vector.
> But if X is 1 by 2, then X[0] will be a scalar?
> Ouch!
> Bye bye generic code.
Yup. That's the current state of things.
Stéfan
___
Numpy-discussion
On Thu, 24 Apr 2008, Christopher Barker apparently wrote:
> I suppose a "Vector" can be either a (n,1) or a (1,n)
> matrix that allows single indexing.
This bothers me.
So, if X is 2 by 2, then X[0] will be a row vector.
But if X is 1 by 2, then X[0] will be a scalar?
Ouch!
Bye bye generic code
On Wed, 23 Apr 2008, Timothy Hochberg apparently wrote:
> I think the way to go is to probably add some meta
> information
I have added this as Proposal 4 at
http://www.scipy.org/MatrixIndexing>
Forgive anything said the misrepresents your intent.
Cheers,
Alan
On Thu, 24 Apr 2008, Christopher Barker apparently wrote:
> for r in MyMatrix.A:
Of course: this possibility is mentioned explicitly in
several of my posts. There are a few different answers to
why asking users to do this annoying:
1. It is a deviation from the behavior of 2d arrays
Alan G Isaac wrote:
> the
> cost of complexity should be justified by a gain in
> functionality.
I don't think functionality is the right word here. the Matrix class(es)
is all about clean, convenient API, i.e. style, not functionality -- we
have all the functionality already, indeed we have i
On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote:
> Assuming we want the next version to : ignore values outside of range and
> accept and return the bin edges instead of the left edges, here could be the
> new signature for 1.1:
> h, edges = histogram(a, bins=10, normed=False, range=None, norm
The problem I see with C is that it will break compatibility with the other
histogram functions, which also use bins.
So here is suggestion E:
The most common use case ( I think) is the following:
h, b = histogram(r, number_of_bins, normed=True/False) for which the
function behaves correctly.
As
Pauli Virtanen wrote:
>
> C) Create a new parameter with more sensible behavior and a name
> different from "bins", and deprecate (at least giving sequences to) the
> "bins" parameter: put up a DeprecationWarning if the user does this, but
> still produce the same results as the old histogram.
I think a long term strategy needs to be adopted for histogram.
Right now there is a great confusion in what the "bins" keyword
does. Right now it is defined as the lower edge of each bin, meaning
that the last bin is open ended and [inf,bin0> does not exist. While
this may not be the right thing t
Wed, 23 Apr 2008 16:20:41 -0400, David Huard wrote:
> 2008/4/23, Stéfan van der Walt <[EMAIL PROTECTED]>:
> > Of those tickets, the following are serious:
> >
> > http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is
> > available?, David Huard)
> > Fixing of histogram.
>
> I haven't found
> אל: Discussion of Numerical Python
> נושא: Re: [Numpy-discussion] numpy release
>
> 2008/4/24 Nadav Horesh <[EMAIL PROTECTED]>:
>
>> +1
>>
>
> +1 to what? I'm glad that Tim chimed in -- his opinion is always
> valued -- but I didn't se
demonstrates an
alternative.
Nadav.
-הודעה מקורית-
מאת: [EMAIL PROTECTED] בשם St?fan van der Walt
נשלח: ה 24-אפריל-08 13:13
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] numpy release
2008/4/24 Nadav Horesh <[EMAIL PROTECTED]>:
> +1
+1 to what? I'm glad that
2008/4/24 Nadav Horesh <[EMAIL PROTECTED]>:
> +1
+1 to what? I'm glad that Tim chimed in -- his opinion is always
valued -- but I didn't see any concrete suggestions on how to improve
the situation. I'll gladly wait for his code, though :)
Regards
Stéfan
+1
Nadav
-הודעה מקורית-
מאת: [EMAIL PROTECTED] בשם Timothy Hochberg
נשלח: ה 24-אפריל-08 04:16
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] numpy release
[CHOP]
The proposals thus far don't address two of the major issues I have with the
matrix class:
1
On Wed, 23 Apr 2008, Bill Spotz apparently wrote:
> Gains: (1) non-scalar extractions from linear algebra
> objects ARE and BEHAVE like linear algebra objects;
I believe this is not a gain, since there is a standard way to
do this now, which would remain under the second proposal.
> (2) a clear
[CHOP]
The proposals thus far don't address two of the major issues I have with the
matrix class:
1. The matrices and arrays should become more alike if possible and
should share more of the same code base. From what I've seen, the people who
write the code (for numpy) don't actually use
2008/4/23 Christopher Barker <[EMAIL PROTECTED]>:
> Aside from the fact that someone needs to write the code -- why don't
> people like the row/column vector idea? It just feels so natural to me:
I wrote most of the code last week (see the previous thread on the
mailing list for a patch). It cu
On Apr 23, 2008, at 3:55 PM, Christopher Barker wrote:
>> For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the
>> array
>> attribute of a Row Vector or Column Vector be 1d?
>
> Absolutely -- a vector is a 1-d array. The only difference here is
> that
> we can preserve the concept o
Alan Isaac wrote:
> I have updated http://www.scipy.org/MatrixIndexing>
> to reflect this change (and its provisional status).
Thanks for writing this up -- it really clarifies what's being proposed.
A few comments on that write up:
> For matrix x, should x[0].A[0] == x.A[0][0]? That is, should
On Wed, 23 Apr 2008, Stéfan van der Walt wrote:
> Done in r5072.
Much appreciated.
I have updated http://www.scipy.org/MatrixIndexing>
to reflect this change (and its provisional status).
Alan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.
2008/4/23 Jarrod Millman <[EMAIL PROTECTED]>:
> On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
> <[EMAIL PROTECTED]> wrote:
> > > So ... fixing x[0][0] for matrices should wait
> > > until 1.2. Is that correct?
> >
> > It seems to me that everyone agrees that the current situation is
>
2008/4/23, Stéfan van der Walt <[EMAIL PROTECTED]>:
>
> Hi Jarrod
>
> Of those tickets, the following are serious:
>
> http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is
> available?, David Huard)
> Fixing of histogram.
>
I haven't found a way to fix histogram reliably without breaking
On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> > So ... fixing x[0][0] for matrices should wait
> > until 1.2. Is that correct?
>
> It seems to me that everyone agrees that the current situation is
> broken, but there is considerable disagreement on what the cor
On 23/04/2008, Alan Isaac <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Apr 2008, Sebastian Haase wrote:
> > What used to be referred to a the 1.1 version, that can
> > break more stuff, to allow for a cleaner design, will now
> > be 1.2
>
> So ... fixing x[0][0] for matrices should wait
> until 1.2.
On Wed, 23 Apr 2008, Sebastian Haase wrote:
> What used to be referred to a the 1.1 version, that can
> break more stuff, to allow for a cleaner design, will now
> be 1.2
So ... fixing x[0][0] for matrices should wait
until 1.2. Is that correct?
Thank you,
Alan Isaac
_
Hi Jarrod
Of those tickets, the following are serious:
http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is
available?, David Huard)
Fixing of histogram.
http://projects.scipy.org/scipy/numpy/ticket/551 (old regression,
Chuck and Travis)
Unpickled arrays don't work as expected, becau
On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> The question is: what blocks the release of 1.1? The following
> tickets deserve attention:
>
> http://projects.scipy.org/scipy/numpy/ticket/750
> http://projects.scipy.org/scipy/numpy/ticket/605
> http://projec
On Wed, Apr 23, 2008 at 4:56 PM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> > > Hi Jarrod,
> > >
> > > any news with the 1.0.5? If y
On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> > Hi Jarrod,
> >
> > any news with the 1.0.5? If you have same prerelease, I'd like to test
> > it. Debian has just moved from python2.4 to
2008/4/23 Ondrej Certik <[EMAIL PROTECTED]>:
> What is the plan with the release? There are some minor problems in
> the Debian package, some of which are fixed by the new release.
> I didn't fix those in Debian as I thought the new release is coming
> out. But if it's going to take let's say m
On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> Hi Jarrod,
>
> any news with the 1.0.5? If you have same prerelease, I'd like to test
> it. Debian has just moved from python2.4 to python2.5 yesterday, so
> I'd like to test numpy in advance, I am sure there will be so
Hey,
This is just a short note to explain the plan for future release
numbering. Basically, we are just going to be much more rigorous
about following everyone's expectations about release numbers.
1.1.0 will be released ASAP and will include some minor API breakage
and new features
1.1.x will
Hi Jarrod,
any news with the 1.0.5? If you have same prerelease, I'd like to test
it. Debian has just moved from python2.4 to python2.5 yesterday, so
I'd like to test numpy in advance, I am sure there will be some issues
to fix.
Ondrej
___
Numpy-discuss
56 matches
Mail list logo
