numpy release

classic Classic list List threaded Threaded
153 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

numpy release

Ondrej Certik
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-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Ondrej Certik
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Stéfan van der Walt
2008/4/23 Ondrej Certik <[hidden email]>:
>  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 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]

Regards
Stéfan
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Sebastian Haase
In reply to this post by Ondrej Certik
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 non-backwards 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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Ondrej Certik
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 non-backwards 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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Jarrod Millman
In reply to this post by Stéfan van der Walt
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/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/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Stéfan van der Walt
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/
>
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Alan G Isaac
In reply to this post by Sebastian Haase
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




_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Anne Archibald
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Jarrod Millman
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/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

David Huard
In reply to this post by Stéfan van der Walt


2008/4/23, Stéfan van der Walt <[hidden email]>:
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 the current behavior. There is a patch attached to the ticket, if the decision is to break histogram.

David

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Stéfan van der Walt
In reply to this post by Jarrod Millman
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Alan G Isaac
On Wed, 23 Apr 2008, Stéfan van der Walt wrote:
> Done in r5072.

Much appreciated.
I have updated <URL:http://www.scipy.org/MatrixIndexing>
to reflect this change (and its provisional status).
Alan



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Chris Barker - NOAA Federal
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 1-d 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 1-d 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 2-d array with some functionality overloaded to make it
convenient to do linear algebra.

A vector is a 1-d 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) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

[hidden email]
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

wfspotz-sandia
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 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 1-d 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 Matrix-Matrix 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) non-scalar 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 2-d array with some functionality overloaded to make it
> convenient to do linear algebra.
>
> A vector is a 1-d 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 full-fledged 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  
Krylov-space iterative method, and what that type of interface would  
lead to the most readable code.

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: [hidden email] **






_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Stéfan van der Walt
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Tim Hochberg
In reply to this post by wfspotz-sandia

[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 hand-wavey; 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

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Alan G Isaac
In reply to this post by wfspotz-sandia
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 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



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Nadav Horesh
In reply to this post by Tim Hochberg

+1

  Nadav

-----הודעה מקורית-----
מאת: [hidden email] בשם 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. 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 hand-wavey; 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


_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion

winmail.dat (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: numpy release

Stéfan van der Walt
2008/4/24 Nadav Horesh <[hidden email]>:
> +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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
1234 ... 8