Since I am the one who initially proposed the RowVector/ColumnVector
idea, I have followed the discussion here with interest. However,
since I typically deal with sparse matrices, I didn't feel like I had
much to contribute to the indexing issues. But now that we are
getting into sparse m
Alan G Isaac wrote:
>> On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>>
>>> - it retains more ndarray behavior
>>>
>
>
> On Thu, 17 Apr 2008, Stéfan van der Walt apparently wrote:
>
>> That is simply not true. The patch I sent provides everything you
>> asked for w
> On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> - it retains more ndarray behavior
On Thu, 17 Apr 2008, Stéfan van der Walt apparently wrote:
> That is simply not true. The patch I sent provides everything you
> asked for without breaking any ndarray behaviour, whereas your
Hi Joris
On 17/04/2008, Joris De Ridder <[EMAIL PROTECTED]> wrote:
> The patch introduces "Vector", but I assume it's your intend to change
> this into "RowVector" or "ColumnVector" in the end, correct?
This was just of a proof of concept. It depends very much on what you
guys want.
Vector curr
On 17/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> I have mixed feelings on all of this discussion. I do want to make
> sure, however, that two ideas are considered:
>
> 1) How will sparse matrices behave? It seems to me that the matrix
> object and sparse matrices should behave id
On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Stefan's scores well too, so why do I prefer mine?
> As I said, I am not sure mine is better, but I think it is,
> an I can offer some reasons to prefer it. Two are:
>
> - it is simpler
> - it retains more ndarray behavior
On 17 Apr 2008, at 01:09, Stéfan van der Walt wrote:
> Split infinitive -- I'd get in trouble for that.
>
> Please use the latest patch (attached), which fixes a bug with
> assignment.
>
> I experimented with returning an (N,) array when converting using
> vector.A, but I'm not convinced that t
Alan G Isaac wrote:
> On Thu, 17 Apr 2008, Gael Varoquaux apparently wrote:
>
>> I am sorry, I don't see why you prioritize "x[i][j] == x[i,j]" (1) more than
>> "x[0] == x[0,:]" (2).
>>
>
> Well the quick answer is:
> use matrices for awhile,
> and I expect you will see why,
> and teach t
On Thu, 17 Apr 2008, Gael Varoquaux apparently wrote:
> I am sorry, I don't see why you prioritize "x[i][j] == x[i,j]" (1) more than
> "x[0] == x[0,:]" (2).
Well the quick answer is:
use matrices for awhile,
and I expect you will see why,
and teach them for awhile, and
I am quite sure you will s
On 17/04/2008, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > It is not a breakdown.
> > It is the proposal:
> > restore the proper behavior of x[0],
> > but keep submatrix extraction **exactly**
> > the same as it is now (for n
On Wed, Apr 16, 2008 at 06:02:53PM -0400, Alan G Isaac wrote:
> On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote:
> > I showed you exactly where your proposal breaks down --
> > numerous times: x[0] is no longer the same as x[0,:]
> And as I explained back: this is a good thing (TM).
>
On 17/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> It is not a breakdown.
> It is the proposal:
> restore the proper behavior of x[0],
> but keep submatrix extraction **exactly**
> the same as it is now (for nonscalar indexes).
>
> What it gains is that x[i][j] == x[i,j].
As the patch
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote:
> I showed you exactly where your proposal breaks down --
> numerous times: x[0] is no longer the same as x[0,:]
And as I explained back: this is a good thing (TM).
There is no need for these to be the same.
I also gave you the simple r
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote:
> Do you think that a (column) vector should convert to a 1d
> array?
Yes: for consistency with row vector conversion,
and for indexing consistency.
Again, I understand what you have done, and it addresses
my core issue. I do not "obje
On 16/04/2008, Alan Isaac <[EMAIL PROTECTED]> wrote:
> It seems lots of complexity for a payoff I do not see.
> My proposal is simpler and stays closer to ndarray behavior.
I showed you exactly where your proposal breaks down -- numerous times:
x[0] is no longer the same as x[0,:]
> But having
> On 16/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> The rule is:
>> to get a submatrix,
>> use multiple indices.
On Wed, 16 Apr 2008, Stéfan van der Walt wrote:
> That is not the rule for arrays; you argued the compatibility point yourself.
Sorry, I do not understand.
I am saying only:
On Wed, 16 Apr 2008, Gael Varoquaux wrote:
> let us pretend A[:, 1] returns a 1D array, as you seem to
> be wanting
Where did I say anything like that??
Please look at the proposal.
It affects **only** scalar indexing
(and thereby iteration).
Recall how emphatically I agreed with you:
Multiple
On Wed, Apr 16, 2008 at 11:01 AM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 10:06:05AM -0400, Alan G Isaac wrote:
> > > if you want a submatrix you should provide both indices
> > > (possibly including a ":").
>
> > Yes. We exactly agree on this.
> > Please persuade Ste
On Wed, Apr 16, 2008 at 10:06:05AM -0400, Alan G Isaac wrote:
> > if you want a submatrix you should provide both indices
> > (possibly including a ":").
> Yes. We exactly agree on this.
> Please persuade Stefan.
Alan, instead of trying blindly to persuade Stefan, please listen to his
arguments
On 16/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> The rule is:
> to get a submatrix,
> use multiple indices.
> As Anne has argued,
> this is natural.
That is *not* the rule for arrays; you argued the compatibility point yourself.
> As far as I know, no objections have been raised by us
On Wed, Apr 16, 2008 at 9:26 AM, Konrad Hinsen <[EMAIL PROTECTED]>
wrote:
> On Apr 15, 2008, at 11:41, Gael Varoquaux wrote:
>
> > On Tue, Apr 15, 2008 at 01:38:45AM -0500, Robert Kern wrote:
> >>> Given that the next release will be 1.1, I think it is
> >>> reasonable to
> >>> include a few add
On Wed, Apr 16, 2008 at 8:06 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008, Anne Archibald apparently wrote:
> > My (draconian) suggestion would be to simply raise an
> > exception when a matrix is indexed with a scalar.
>
> This has been suggested before. But then, why?
> Aga
On Apr 15, 2008, at 11:41, Gael Varoquaux wrote:
> On Tue, Apr 15, 2008 at 01:38:45AM -0500, Robert Kern wrote:
>>> Given that the next release will be 1.1, I think it is
>>> reasonable to
>>> include a few additional API breaks.
>
>> -lots. I don't want to break API compatibility again no mat
On Wed, 16 Apr 2008, Anne Archibald apparently wrote:
> My (draconian) suggestion would be to simply raise an
> exception when a matrix is indexed with a scalar.
This has been suggested before. But then, why?
Again, this imposes a deviation from the behavior of
arrays that provides no gain in fu
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote:
> Your proposal suggests that a Matrix be a container of arrays, but it
> does not address the slicing of column vectors, i.e.
> x[0]
> x[0,:]
> x[:,0]
The only thing that changes is the handling of scalar
indices (and thus of itera
On 16/04/2008, Anne Archibald <[EMAIL PROTECTED]> wrote:
> I don't think of arrays as containers of anything but scalars, so I
> find this whole argument from intuition extremely strange.
I see now for the first time that Matrices can't have dims > 2. Grim.
I do think that ColumnVector and RowV
On 16/04/2008, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> On 16/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > > The whole issue occurs because a Matrix is not a proper
> > > container.
> >
> >
> > Right. And *that* is the case because of the attempt to
> > treat matrices as c
On 16/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > The whole issue occurs because a Matrix is not a proper
> > container.
>
>
> Right. And *that* is the case because of the attempt to
> treat matrices as containers of matrices instead of as
> containers of 1d arrays.
>
> I can see no
> On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> I thought the context of the discussion had become something
>> like this: there is no reason for the matrix interface to
>> deviate from the array interface except as needed to provide
>> specific desired functionality. Essentially,
On Tue, 15 Apr 2008, Anne Archibald apparently wrote:
> This discussion risks going around in circles. Write up
> your proposed solutions, with example code, in PEP style,
> here:
> http://www.scipy.org/ProposedEnhancements
Done: http://www.scipy.org/MatrixIndexing
I am a NumPy user, not a Nu
Sebastian Haase wrote:
> On Tue, Apr 15, 2008 at 9:41 AM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Apr 15, 2008 at 2:31 AM, Jon Wright <[EMAIL PROTECTED]> wrote:
>> > Alan G Isaac wrote:
>> > >
>> > > Will matrix behavior change in 1.1, as discussed from time
>> > > to time? P
On 15/04/2008, Jon Wright <[EMAIL PROTECTED]> wrote:
> > On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>
> ...
>
> > The proposal on the table is to remove an unneeded (and
> > unwanted) deviation of the matrix API from the ndarray API.
>
> ...
>
> How about writing up the changes need
> On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
...
> The proposal on the table is to remove an unneeded (and
> unwanted) deviation of the matrix API from the ndarray API.
...
How about writing up the changes needed PEP style on the wiki?
> The fix appears to be a very small change in
On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> I thought the context of the discussion had become something
> like this: there is no reason for the matrix interface to
> deviate from the array interface except as needed to provide
> specific desired functionality. Essentially,
>
>
> On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> Fixing this has been under discussion for the 1.1
>> release
>> for some time now. To my recollection, no users of matrices
>> objected, and the abstract objections from non-users
>> subsided.
On Tue, 15 Apr 2008, Stéfan van der W
On 15/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Apr 2008, Jarrod Millman apparently wrote:
> Fixing this has been under discussion for the 1.1 release
> for some time now. To my recollection, no users of matrices
> objected, and the abstract objections from non-users
> subs
As a developper for a community that's using massively the old numeric
maksed arrays (MA), I'll just add my 2 cents worth...
I think what's in the trunk right now (at least last week) is ok, the
new ma, with the oldnumeric.ma This allow to still be backward
compatible for a while and change our
On Tue, 15 Apr 2008, Jarrod Millman apparently wrote:
> However, when our current API is "broken" we should be
> open to the possibility that in may need to be fixed.
> Functions with anomalous interfaces seem like a good
> example of candidates that would be worth modifying.
> However, we ne
Sebastian Haase wrote:
> How about releasing 1.0.5 without the new masked array,
> i.e.
> 1. put back the old masked array and release as 1.0.5
> 2. then release 1.1.0 with the new masked array
> 3. start working on 1.2 by unifying the arguments, "np.resize", and
> other things alike.
>
> --Sebast
On Tue, Apr 15, 2008 at 01:38:45AM -0500, Robert Kern wrote:
> > Given that the next release will be 1.1, I think it is reasonable to
> > include a few additional API breaks.
> -lots. I don't want to break API compatibility again no matter what
> version number we bump to, 1.1, 2.0, or 24. It is
On Tue, Apr 15, 2008 at 10:59 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 15, 2008 at 1:35 AM, David Cournapeau
>
> <[EMAIL PROTECTED]> wrote:
>
> > Sebastian Haase wrote:
> > > How about releasing 1.0.5 without the new masked array,
> > > i.e.
> > > 1. put back the old masked
On Tue, Apr 15, 2008 at 1:35 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Sebastian Haase wrote:
> > How about releasing 1.0.5 without the new masked array,
> > i.e.
> > 1. put back the old masked array and release as 1.0.5
>
> Now that it is done, going back will be a lot of work. It woul
Sebastian Haase wrote:
>
>
> How about releasing 1.0.5 without the new masked array,
> i.e.
> 1. put back the old masked array and release as 1.0.5
Now that it is done, going back will be a lot of work. It would be great
if someone were willing to do it, but who ?
cheers,
David
On Tue, Apr 15, 2008 at 9:56 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Sebastian Haase wrote:
> >
> > So, to summarize one more time:
> > """
> > What used to be talked about as "1.1" will now become "1.2" ---
> > and "1.0.5" will be "1.1"
> > """
> >
> > Did I get this right !?
>
On Tue, Apr 15, 2008 at 12:56 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> > Please keep in mind that there are a number of these "awkward"
> > "wrong-default" arguments. I was hoping these would be unified [e.g.
> > always same default, axis=None] very soon -- that is in 1.1.
>
> Is thi
Sebastian Haase wrote:
>
> So, to summarize one more time:
> """
> What used to be talked about as "1.1" will now become "1.2" ---
> and "1.0.5" will be "1.1"
> """
>
> Did I get this right !?
>
> I'm curious to know _which_ were the changes that break the API. I
> thought all additions like "axis=
On Tue, Apr 15, 2008 at 9:41 AM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 15, 2008 at 2:31 AM, Jon Wright <[EMAIL PROTECTED]> wrote:
> > Alan G Isaac wrote:
> > >
> > > Will matrix behavior change in 1.1, as discussed from time
> > > to time? Perhaps it just takes a very small c
On Tue, Apr 15, 2008 at 2:31 AM, Jon Wright <[EMAIL PROTECTED]> wrote:
> Alan G Isaac wrote:
> >
> > Will matrix behavior change in 1.1, as discussed from time
> > to time? Perhaps it just takes a very small change in __getitem__:
> > http://www.mail-archive.com/numpy-discussion@scipy.org/msg0
Alan G Isaac wrote:
>
> Will matrix behavior change in 1.1, as discussed from time
> to time? Perhaps it just takes a very small change in __getitem__:
> http://www.mail-archive.com/numpy-discussion@scipy.org/msg07363.html>
Quoting from:
http://mail.python.org/pipermail/python-dev/2008-March/07
Robert Kern wrote:
>
> -lots. I don't want to break API compatibility again no matter what
> version number we bump to, 1.1, 2.0, or 24. It is simply not okay to
> do this again and again.
>
>
I didn't dare saying anything, but now that I see I am not the only one,
I can sheepishly say I agree
On Mon, Apr 14, 2008 at 11:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> > Given that the next release will be 1.1, I think it is reasonable to
> > include a few additional API breaks.
>
> -lots. I don't want to break API compatibility again no matter what
> version number we bump to, 1.1,
On Tue, Apr 15, 2008 at 1:33 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 10:54 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
> > > Let's not rush 1.1, then.
> >
> > Will matrix behavior change in 1.1, as dis
On Mon, Apr 14, 2008 at 10:54 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
> > Let's not rush 1.1, then.
>
> Will matrix behavior change in 1.1, as discussed from time
> to time? Perhaps it just takes a very small change in __getitem__:
>
On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
> Let's not rush 1.1, then.
Will matrix behavior change in 1.1, as discussed from time
to time? Perhaps it just takes a very small change in __getitem__:
http://www.mail-archive.com/numpy-discussion@scipy.org/msg07363.html>
Cheers,
Alan I
On Mon, Apr 14, 2008 at 10:38 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Let's not rush 1.1, then. I think with another week or two we should be able
> to settle most of the outstanding bugs and it would be good to do so before
> getting caught up in planning 1.2.
+1. I think that we are s
On Mon, Apr 14, 2008 at 11:28 PM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > I think we have a long way to go to get to 1.1. What API changes have we
> > made that are so great that we can't release 1.0.5? The onl
On Mon, Apr 14, 2008 at 10:28 PM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > I think we have a long way to go to get to 1.1. What API changes have we
> > made that are so great that we can't release 1.0.5? The o
On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> I think we have a long way to go to get to 1.1. What API changes have we
> made that are so great that we can't release 1.0.5? The only area where I
> have seen real problems is in masked arrays. My preference would be
Charles R Harris wrote:
>
> I think we have a long way to go to get to 1.1. What API changes have
> we made that are so great that we can't release 1.0.5? The only area
> where I have seen real problems is in masked arrays. My preference
> would be to release the trunk as 1.0.5, and if not, simp
On Mon, Apr 14, 2008 at 10:59 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:
> After the SciPy sprints some useful discussions took place that helped
> us all realize that we have made enough changes to the code base that we
> will need to call any release from the trunk 1.1
>
> I don't think t
On Mon, Apr 14, 2008 at 9:59 PM, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
> So, the question is. Do we have enough energy in the community to
> release the current trunk as 1.1 as well as release 1.0.5 which does not
> contain any of the code/api changes, but just the bug fixes? The answe
After the SciPy sprints some useful discussions took place that helped
us all realize that we have made enough changes to the code base that we
will need to call any release from the trunk 1.1
I don't think that is a big problem. However, there have also been a
lot of substantial bug fixes t
El dg 01 de 04 del 2007 a les 21:35 +0200, en/na Francesc Altet va
escriure:
> El ds 31 de 03 del 2007 a les 21:54 -0600, en/na Travis Oliphant va
> escriure:
> > I'm going to be tagging the tree for the NumPy 1.0.2 release tomorrow
> > evening in preparation for the release on Monday. I've close
El ds 31 de 03 del 2007 a les 21:54 -0600, en/na Travis Oliphant va
escriure:
> I'm going to be tagging the tree for the NumPy 1.0.2 release tomorrow
> evening in preparation for the release on Monday. I've closed several
> bugs. Are there any show-stoppers remaining to be fixed?
Mmm... PyTabl
I'm going to be tagging the tree for the NumPy 1.0.2 release tomorrow
evening in preparation for the release on Monday. I've closed several
bugs. Are there any show-stoppers remaining to be fixed?
-Travis
___
Numpy-discussion mailing list
Numpy-di
65 matches
Mail list logo
