
1234
... 8

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik < [hidden email]> 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 some issues
> to fix.
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 month or two, I'll fix the
current Debian package now.
Thanks,
Ondrej
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik < [hidden email]> wrote:
> On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik < [hidden email]> 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 some issues
> > to fix.
>
> 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 month or two, I'll fix the
> current Debian package now.
>
The problem is, that it was noticed that nonbackwards compatible
changes were committed into svn.
Most noticeably a complete rewrite of the "ma" (Masked Array) package was done.
As a consequence it was decided, they no one would be interested in
"temporarily taking those changes out" "just to release 1.0.5".
Instead the next release will be called 1.1  which is (only; rather
still) "mostly" compatible with 1.0.x
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
HTH,
Sebastian Haase
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Wed, Apr 23, 2008 at 4:56 PM, Sebastian Haase < [hidden email]> wrote:
>
> On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik < [hidden email]> wrote:
> > On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik < [hidden email]> 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 some issues
> > > to fix.
> >
> > 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 month or two, I'll fix the
> > current Debian package now.
> >
>
> The problem is, that it was noticed that nonbackwards compatible
> changes were committed into svn.
> Most noticeably a complete rewrite of the "ma" (Masked Array) package was done.
> As a consequence it was decided, they no one would be interested in
> "temporarily taking those changes out" "just to release 1.0.5".
>
> Instead the next release will be called 1.1  which is (only; rather
> still) "mostly" compatible with 1.0.x
> 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
OK, so I think we are going to try to fix the package in Debian right
now and not wait for the release.
I think this uncertainty about releases and about backward
compatibility is not good. The same about uncertainty where f2py is
going to end up.
But you know the drill "talk is cheap, show me the code", so I know I
could step up and help Jarrod with the release, but unfortunately, I
don't have time for it. :)
Ondrej
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt < [hidden email]> wrote:
I was still hoping to get 1.1.0 out ASAP. Unfortunately, I have been
too busy for the last week to pay attention to the release blockers.
The last time I looked the only issues I felt absolutely needed to be
resolved before the release were:
1. Testing the Windows binary, which is now done.
2. Testing the Mac binary, which is now done.
3. Testing or removing fromregex, which is now done:
http://projects.scipy.org/scipy/numpy/ticket/719I haven't looked carefully at the above tickets, but at a cursory
glance it didn't seem like there were any new regressions. Stefan
could you confirm that? If so, I would like to branch 1.1.x and tag
1.1.0 on Friday night. Unless there is some concrete reason that we
need to delay this release any longer, I will send out an email later
today with an 'official' timeline for the release, which will probably
be on Monday if I tag on Friday night.
Thanks,

Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


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, because of memory alignment issues.
http://projects.scipy.org/scipy/numpy/ticket/748 (old regression, Stefan)
ifft pads incorrectly. I can fix this tonight, if someone would
verify that this is, indeed, a bug.
http://projects.scipy.org/scipy/numpy/ticket/751 (old/new regression,
Stefan, David C*)
ALL section not recognised in site.cfg. In Python 2.6, the DEFAULT
section no longer works. I replaced it with ALL, but apparently not
everything works as expected. David has a way to reproduce the
problem, so I hope he can have a look, otherwise I'll try and fix it
tomorrow.
Regards
Stéfan
2008/4/23 Jarrod Millman < [hidden email]>:
> On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt < [hidden email]> 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://projects.scipy.org/scipy/numpy/ticket/551> > http://projects.scipy.org/scipy/numpy/ticket/738> > http://projects.scipy.org/scipy/numpy/ticket/743> > http://projects.scipy.org/scipy/numpy/ticket/748> > http://projects.scipy.org/scipy/numpy/ticket/751> > http://projects.scipy.org/scipy/numpy/ticket/736> >
> > Further issues:
> >
> >  Alan's matrix indexing: x[0][0] for matrices currently yield x[0]
>
> I was still hoping to get 1.1.0 out ASAP. Unfortunately, I have been
> too busy for the last week to pay attention to the release blockers.
> The last time I looked the only issues I felt absolutely needed to be
> resolved before the release were:
> 1. Testing the Windows binary, which is now done.
> 2. Testing the Mac binary, which is now done.
> 3. Testing or removing fromregex, which is now done:
> http://projects.scipy.org/scipy/numpy/ticket/719>
> I haven't looked carefully at the above tickets, but at a cursory
> glance it didn't seem like there were any new regressions. Stefan
> could you confirm that? If so, I would like to branch 1.1.x and tag
> 1.1.0 on Friday night. Unless there is some concrete reason that we
> need to delay this release any longer, I will send out an email later
> today with an 'official' timeline for the release, which will probably
> be on Monday if I tag on Friday night.
>
> Thanks,
>
> 
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> http://cirl.berkeley.edu/>
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On 23/04/2008, Alan Isaac < [hidden email]> 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. Is that correct?
It seems to me that everyone agrees that the current situation is
broken, but there is considerable disagreement on what the correct fix
is. My inclination is to apply the minimal fix you suggest, with tests
and documentation, as a stopgap, and let the different factions sort
it out by discussion on the way to 1.2.
Objections?
Anne
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
< [hidden email]> 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 correct fix
> is. My inclination is to apply the minimal fix you suggest, with tests
> and documentation, as a stopgap, and let the different factions sort
> it out by discussion on the way to 1.2.
+1
That sound reasonable to me.

Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


2008/4/23 Jarrod Millman < [hidden email]>:
> On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
> < [hidden email]> 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 correct fix
> > is. My inclination is to apply the minimal fix you suggest, with tests
> > and documentation, as a stopgap, and let the different factions sort
> > it out by discussion on the way to 1.2.
>
> +1
> That sound reasonable to me.
Done in r5072.
Cheers
Stéfan
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


Alan Isaac wrote:
> I have updated <URL: 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 the array
> attribute of a Row Vector or Column Vector be 1d?
Absolutely  a vector is a 1d array. The only difference here is that
we can preserve the concept of a row vs. a column vector  key to
linear algebra, which is the whole point of the Matrix class. I'd be
just as happy if a RowVector an ColumnVector were a more unique object
 a 1d array with the operation overloaded, rather than a (1,n) or
(n,1) matrix, but I understand that would be more work.
> Deviations from the behavior of ndarrays. Specifically, iteration over
> a matrix will not yield 1d NumPy arrays.
Why should they? indexing a nested list gives a different result than
indexing an ndarray, etc, etc, etc. The POINT of matrixes is that they
are different! This proposal makes them a little more similar to
ndarrays than the old behavior (always returning a matrix).
> Inconsistency in the indexing style for producing row vectors and
> column vectors
not really:
row vector: M[i,:]
column vector: M[:,i]
The fact that there is another way to get a row vector: M[i] is a bonus.
I once proposed making M[i] raise an exception for the sake of enforcing
consistency, but no one liked that!
> Loss of a standard way to extract a row or a column as a submatrix
> (rather than a vector)
What's wrong with:
M[i:i+1, :] and M[:, i:i+1]
This is totally consistent with arrays (and other python sequences).
Yes, it's a bit more awkward, but with the new vectors, it's also going
to be needed far less.
> No clear gain in functionality over the simpler proposal 2.
Well, I won't judge what's "clear" but I think this adds functionality.
The concept of row and column vectors is a key part of linear algebra.
Sure, you can model them as matrixes that happen to have only one row or
one column, but that's what we had, but there seem to be real issues
with use of that. Option (2), is "Let a Matrix be a container of 1d
arrays.". Sounds simple, but do those arrays represent row or column
vectors? Either would make sense. The proposal is for them to be row
vectors, which is fine, but then if you want them to act like a row
vectors, do you need to convert them back into matrices? Even if not,
how do you get a column vector  by indexing the current way, and
getting a (n,1) matrix, so that now we have inconsistency between how
row and column vectors are treated  not a clean API.
And this is about a clean API for linear algebra  otherwise, we'd just
all use arrays (which many do!)
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:
A matrix is a 2d array with some functionality overloaded to make it
convenient to do linear algebra.
A vector is a 1d array with some functionality overloaded to make it
convenient to do linear algebra.
A scalar is the same in both contexts, so no need to change anything there.
And yes, maybe this will lead to tensors some day!
Another couple questions:  would there be constructors for vectors?
np.RowVector((1,2,3,4,5))
np.ColumnVector((1,2,3,4,5,6))
and would:
A_RowVector.T == A_ColumnVector
I would think so.
One more note:
All the example code I've seen during this discussion have been examples
of iterating and indexing  not one has actually been linear algebra 
perhaps we should see some of those before making any decisions.
Chris

Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 5266959 voice
7600 Sand Point Way NE (206) 5266329 fax
Seattle, WA 98115 (206) 5266317 main reception
[hidden email]
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


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 1d array. The only difference here is
> that
> we can preserve the concept of a row vs. a column vector  key to
> linear algebra, which is the whole point of the Matrix class. I'd be
> just as happy if a RowVector an ColumnVector were a more unique object
>  a 1d array with the operation overloaded, rather than a (1,n) or
> (n,1) matrix, but I understand that would be more work.
The way I envisioned this was that RowVector and ColumnVector would
inherit from Matrix, so that you would inherit all of the Matrix
functionality. They would just be special cases where ncol=0 or
nrow=0, allowing single indexing.
If MatrixMatrix multiplication is implemented properly, then the Row/
ColumnVector multiplication operators should automatically work.
>> Inconsistency in the indexing style for producing row vectors and
>> column vectors
>
> not really:
I agree with Alan here. M[i] returns a RowVector, but there is no
corresponding single index way to retrieve a ColumnVector (unless we
want to use __call__() to make M(j) return a ColumnVector . . . but
this is highly unintuitive.)
Thinking out loud: we could support
M[i=#] return a RowVector
M[j=#] return a ColumnVector
M[#] equivalent to M[i=#]
> The fact that there is another way to get a row vector: M[i] is a
> bonus.
Except that the behavior of M[i] is one of the driving issues of the
conversation.
>> Loss of a standard way to extract a row or a column as a submatrix
>> (rather than a vector)
If Row/ColumnVector inherit from Matrix, then this is not strictly
true. There is no reason that these classes could not support [i,j]
indexing, which means they would BE Matrices (inheritence) and they
would BEHAVE like Matrices (except for V[i][j] . . . argh).
>> No clear gain in functionality over the simpler proposal 2.
Gains: (1) nonscalar extractions from linear algebra objects ARE and
BEHAVE like linear algebra objects; (2) a clear path for dense and
sparse matrices to have the same (or at least analogous) interfaces.
> 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:
Unless I'm misremembering, Alan is the only one who has expressed
concerns and he is willing to concede to the design if others agree.
> A matrix is a 2d array with some functionality overloaded to make it
> convenient to do linear algebra.
>
> A vector is a 1d array with some functionality overloaded to make it
> convenient to do linear algebra.
Again, I would argue for Vectors inheriting from Matrix. I would make
the case based on code reuse and elegance, although these might be
overridden by some other concern.
> And yes, maybe this will lead to tensors some day!
Don't see why not.
> Another couple questions:  would there be constructors for vectors?
>
> np.RowVector((1,2,3,4,5))
> np.ColumnVector((1,2,3,4,5,6))
Yes. They should be fullfledged classes, although with inheriting
from Matrix, the implementation should be relatively small. What about
np.Matrix(<container of RowVector>)
np.Matrix(<container of ColumnVector>)
?
> and would:
> A_RowVector.T == A_ColumnVector
Yes.
> All the example code I've seen during this discussion have been
> examples
> of iterating and indexing  not one has actually been linear
> algebra 
> perhaps we should see some of those before making any decisions.
Right. I have generally thought about this in the context of, say, a
Krylovspace iterative method, and what that type of interface would
lead to the most readable code.
** Bill Spotz **
** Sandia National Laboratories Voice: (505)8450170 **
** P.O. Box 5800 Fax: (505)2840154 **
** Albuquerque, NM 871850370 Email: [hidden email] **
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


In reply to this post by Chris Barker  NOAA Federal
2008/4/23 Christopher Barker < [hidden email]>:
> 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 currently only implements Vector (not
RowVector and ColumnVector), but those two would be easy to add.
Cheers
Stéfan
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


[CHOP] The proposals thus far don't address two of the major issues I have with the matrix class:  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 matrices, they use the arrays. This is one of the main reasons matrices still have so many problems IMO; if one of the main developers were using them, they'd never have put up with it. This may be changing to some extent now, but the more we can make matrices and arrays share code and interface, the happier we'll be. None of the new rules strike me as helping in this arena and may in fact hurt. Again, IMO.
 This doesn't support the concept of arrays of matrices/vectors, which is one thing I've always wanted out of the matrix class. For example it would be nice to be able to spell: 'A' is a 1D array of matrices (3D) overall, 'B' is a 1D array of vectors (3D) overall, matrix multiply them together, yielding a 1D array of matrices (3D) overall. I have frequently run into various permutations of this problem. You can fake it with loops over dot, but the efficiency is very bad for small arrays, plus it's ugly.
I have lot's of vague ideas on this subject that have been floating around my head for the past couple of years. Basically, I think the way to go is to probably add some meta information to arrays that make them look a little bit more like tensors. Then, if one is careful (and things work out as I hope) matrices could be implemented as a thin layer on top of arrays. Or perhaps, if we are very lucky, done away with altogether.
Anyway, that's all very vague and handwavey; if I can spring free some time, I'll try to write something up in the not too distant future. I'm glad to see that any major changes are being put off for a while: I think we should be able to do better than just patch up the old matrix class.
tim
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Wed, 23 Apr 2008, Bill Spotz apparently wrote:
> Gains: (1) nonscalar 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 path for dense and sparse matrices to have the
> same (or at least analogous) interfaces.
This may prove true. I'm agnostic.
What actually turns on this?
I believe it is the following:
if iterating over a sparse matrix yields sparse vectors
that behave like a sparse matrix, then iterating over a
matrix should return a vector that behaves like a matrix.
But I have not seen any detailed discussion of this design
issue. E.g., iterating over a sparse matrix could yield
instead a sparse object that behaves like a 1d array.
I should add that if the first approach is taken,
I agree that it is natural for these "vectors" to
inherit from matrix.
With respect to the matrix object, my only "objection" has
been that I'd like to hear someone state clearly what
functionality is gained by following the more complex first
proposal instead of the second proposal. The reason: the
cost of complexity should be justified by a gain in
functionality. It *may* be that the link between the
behavior of matrices and that of sparse matrices is where
the gain manifests, but that is not yet clear to me.
> Unless I'm misremembering, Alan is the only one who has
> expressed concerns and he is willing to concede to the
> design if others agree.
I'm in no position to concede or not concede anything,
since I am not writing code, but my core concerns
will be met by either proposal.
Thanks!
Alan
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


+1
Nadav
הודעה מקורית
מאת: [hidden email] בשם Timothy Hochberg
נשלח: ה 24אפריל08 04:16
אל: Discussion of Numerical Python
נושא: Re: [Numpydiscussion] numpy release
[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 matrices, they use the arrays.
This is one of the main reasons matrices still have so many problems IMO; if
one of the main developers were using them, they'd never have put up with
it. This may be changing to some extent now, but the more we can make
matrices and arrays share code and interface, the happier we'll be. None of
the new rules strike me as helping in this arena and may in fact hurt.
Again, IMO.
2. This doesn't support the concept of arrays of matrices/vectors, which
is one thing I've always wanted out of the matrix class. For example it
would be nice to be able to spell: 'A' is a 1D array of matrices (3D)
overall, 'B' is a 1D array of vectors (3D) overall, matrix multiply them
together, yielding a 1D array of matrices (3D) overall. I have frequently
run into various permutations of this problem. You can fake it with loops
over dot, but the efficiency is very bad for small arrays, plus it's ugly.
I have lot's of vague ideas on this subject that have been floating around
my head for the past couple of years. Basically, I think the way to go is to
probably add some meta information to arrays that make them look a little
bit more like tensors. Then, if one is careful (and things work out as I
hope) matrices could be implemented as a thin layer on top of arrays. Or
perhaps, if we are very lucky, done away with altogether.
Anyway, that's all very vague and handwavey; if I can spring free some
time, I'll try to write something up in the not too distant future. I'm glad
to see that any major changes are being put off for a while: I think we
should be able to do better than just patch up the old matrix class.
tim
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion

1234
... 8
