[Numpy-discussion] Uncomfortable with matrix change

[Travis Oliphant]

Hi all,

I'm having trouble emailing this list from work, so I'm using a 
different email address.

After Nathan Bell's recent complaints, I'm a bit more uncomfortable with 
the matrix change to scalar indexing.   It does and will break code in 
possibly hard-to-track down ways.   Also, Nathan has been a *huge* 
contributor to the Sparse matrix in scipy and so I value his opinion 
about the NumPy matrix.  One of my goals is to have those two objects 
work together a bit more seamlessly.

So, I think we need to:

1) Add a warning to scalar access
2) Back-out the change and fix all the places where NumPy assumes 
incorrectly that the number of dimensions reduce on PySequence_GetItem.

Opinions?

-Travis



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Charles R Harris]

On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant <[EMAIL PROTECTED]>
wrote:

>
> Hi all,
>
> I'm having trouble emailing this list from work, so I'm using a
> different email address.
>
> After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
> the matrix change to scalar indexing.   It does and will break code in
> possibly hard-to-track down ways.   Also, Nathan has been a *huge*
> contributor to the Sparse matrix in scipy and so I value his opinion
> about the NumPy matrix.  One of my goals is to have those two objects
> work together a bit more seamlessly.
>
> So, I think we need to:
>
> 1) Add a warning to scalar access
> 2) Back-out the change and fix all the places where NumPy assumes
> incorrectly that the number of dimensions reduce on PySequence_GetItem.
>

-1.

That said, the basic mistake is probably making Matrix a subclass of
ndarray, as it fails the "is a" test. There really aren't that many places
where inheritance is the right choice and  numpy itself wasn't designed as a
base class: it lacks a specification of what functions can be "virtual" and
is probably too big.

I vote that we bring Nathan into the conversation and see how upset he
really is. Speaking for myself, I sometimes get angry upfront when
specifications change unexpectedly underfoot but then settle down and find
that it isn't all that bad. Being caught by surprise is probably half the
problem.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Fri, 09 May 2008, Travis Oliphant apparently wrote:
> I think we need to:
> 1) Add a warning to scalar access 
> 2) Back-out the change and fix all the places where NumPy assumes  
> incorrectly that the number of dimensions reduce on PySequence_GetItem. 
> Opinions?

Point of information: it looks like Nathan already made the 
needed fixes, and the changes made were in my opinion not at 
all obscure and indeed were rather minor.  (Which does not 
deny they were needed.)

I am trying to advocate either way; just supplying information.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Charles R Harris]

On Fri, May 9, 2008 at 8:00 AM, Charles R Harris <[EMAIL PROTECTED]>
wrote:

>
>
> On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Hi all,
>>
>> I'm having trouble emailing this list from work, so I'm using a
>> different email address.
>>
>> After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
>> the matrix change to scalar indexing.   It does and will break code in
>> possibly hard-to-track down ways.   Also, Nathan has been a *huge*
>> contributor to the Sparse matrix in scipy and so I value his opinion
>> about the NumPy matrix.  One of my goals is to have those two objects
>> work together a bit more seamlessly.
>>
>> So, I think we need to:
>>
>> 1) Add a warning to scalar access
>> 2) Back-out the change and fix all the places where NumPy assumes
>> incorrectly that the number of dimensions reduce on PySequence_GetItem.
>>
>
> -1.
>
> That said, the basic mistake is probably making Matrix a subclass of
> ndarray, as it fails the "is a" test. There really aren't that many places
> where inheritance is the right choice and  numpy itself wasn't designed as a
> base class: it lacks a specification of what functions can be "virtual" and
> is probably too big.
>
> I vote that we bring Nathan into the conversation and see how upset he
> really is. Speaking for myself, I sometimes get angry upfront when
> specifications change unexpectedly underfoot but then settle down and find
> that it isn't all that bad. Being caught by surprise is probably half the
> problem.
>

Let me add that backing it out of 1.1 might not be a bad idea, it may be a
change to soon and at the last minute at that. But I would like to see it in
1.2.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Anne Archibald]

2008/5/9 Travis Oliphant <[EMAIL PROTECTED]>:

> After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
> the matrix change to scalar indexing.   It does and will break code in
> possibly hard-to-track down ways.   Also, Nathan has been a *huge*
> contributor to the Sparse matrix in scipy and so I value his opinion
> about the NumPy matrix.  One of my goals is to have those two objects
> work together a bit more seamlessly.
>
> So, I think we need to:
>
> 1) Add a warning to scalar access
> 2) Back-out the change and fix all the places where NumPy assumes
> incorrectly that the number of dimensions reduce on PySequence_GetItem.
>
> Opinions?

This is certainly the conservative approach.

How much code is broken by this, compared to (say) the amount broken
by the disappearance of numpy.core.ma? Is this our biggest single API
breakage?

I do agree that we should be paying attention to people who are
actually using matrices, so I won't enter a vote.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Bruce Southey]

Charles R Harris wrote:
>
>
> On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant <[EMAIL PROTECTED] 
> > wrote:
>
>
> Hi all,
>
> I'm having trouble emailing this list from work, so I'm using a
> different email address.
>
> After Nathan Bell's recent complaints, I'm a bit more
> uncomfortable with
> the matrix change to scalar indexing.   It does and will break code in
> possibly hard-to-track down ways.   Also, Nathan has been a *huge*
> contributor to the Sparse matrix in scipy and so I value his opinion
> about the NumPy matrix.  One of my goals is to have those two objects
> work together a bit more seamlessly.
>
> So, I think we need to:
>
> 1) Add a warning to scalar access
> 2) Back-out the change and fix all the places where NumPy assumes
> incorrectly that the number of dimensions reduce on
> PySequence_GetItem.
>
>
> -1.
>
> That said, the basic mistake is probably making Matrix a subclass of 
> ndarray, as it fails the "is a" test. There really aren't that many 
> places where inheritance is the right choice and  numpy itself wasn't 
> designed as a base class: it lacks a specification of what functions 
> can be "virtual" and is probably too big.
>
> I vote that we bring Nathan into the conversation and see how upset he 
> really is. Speaking for myself, I sometimes get angry upfront when 
> specifications change unexpectedly underfoot but then settle down and 
> find that it isn't all that bad. Being caught by surprise is probably 
> half the problem.
>
> Chuck
>
>
> 
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>   
Hi,
+1

The prime reason is not whether or not it is a bad/good idea but because 
the actual change was introduced so late in the development of 1.0.5/1.1 
process. A lesser reason is that gives people like Nathan time to change 
their code to match the pending release. Unfortunately the other problem 
with this change is that any user now has to be careful of which NumPy 
version is being used. The result is that backwards compatibility is now 
broken in what was originally going to be a minor release.

Following Tim Hochberg's email on changing histogram, I  think that for 
at least NumPy version 1.1 that scalar indexing should provide a 
'PendingDeprecationWarning' or a 'DeprecationWarning' with the actual 
change happening in 1.2 or later.

Regards
Bruce
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Charles R Harris]

On Fri, May 9, 2008 at 8:51 AM, Bruce Southey <[EMAIL PROTECTED]> wrote:

> Charles R Harris wrote:
> >
> >
> > On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant <[EMAIL PROTECTED]
> > > wrote:
> >
> >
> > Hi all,
> >
> > I'm having trouble emailing this list from work, so I'm using a
> > different email address.
> >
> > After Nathan Bell's recent complaints, I'm a bit more
> > uncomfortable with
> > the matrix change to scalar indexing.   It does and will break code
> in
> > possibly hard-to-track down ways.   Also, Nathan has been a *huge*
> > contributor to the Sparse matrix in scipy and so I value his opinion
> > about the NumPy matrix.  One of my goals is to have those two objects
> > work together a bit more seamlessly.
> >
> > So, I think we need to:
> >
> > 1) Add a warning to scalar access
> > 2) Back-out the change and fix all the places where NumPy assumes
> > incorrectly that the number of dimensions reduce on
> > PySequence_GetItem.
> >
> >
> > -1.
> >
> > That said, the basic mistake is probably making Matrix a subclass of
> > ndarray, as it fails the "is a" test. There really aren't that many
> > places where inheritance is the right choice and  numpy itself wasn't
> > designed as a base class: it lacks a specification of what functions
> > can be "virtual" and is probably too big.
> >
> > I vote that we bring Nathan into the conversation and see how upset he
> > really is. Speaking for myself, I sometimes get angry upfront when
> > specifications change unexpectedly underfoot but then settle down and
> > find that it isn't all that bad. Being caught by surprise is probably
> > half the problem.
> >
> > Chuck
> >
> >
> > 
> >
> > ___
> > Numpy-discussion mailing list
> > Numpy-discussion@scipy.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> >
> Hi,
> +1
>
> The prime reason is not whether or not it is a bad/good idea but because
> the actual change was introduced so late in the development of 1.0.5/1.1
> process. A lesser reason is that gives people like Nathan time to change
> their code to match the pending release. Unfortunately the other problem
> with this change is that any user now has to be careful of which NumPy
> version is being used. The result is that backwards compatibility is now
> broken in what was originally going to be a minor release.
>

Of course, if Nathan has already made the changes we will drive him crazy if
we back them out now ;) I note that the thread on scipy ended pretty
quickly, so I didn't get the impression there was a lot of resistance.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Stéfan van der Walt]

2008/5/9 Anne Archibald <[EMAIL PROTECTED]>:
> How much code is broken by this, compared to (say) the amount broken
> by the disappearance of numpy.core.ma? Is this our biggest single API
> breakage?

You shouldn't import from core -- we never advertised that API.  As
far as I recall, numpy.ma was always available.

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Fri, 9 May 2008, Charles R Harris apparently wrote:
> if Nathan has already made the changes we will drive him 
> crazy if we back them out now

Since I mentioned Nathan's changes, I wish to clarify 
something.  I have no idea what Nathan's views are, but as 
I recall them, it looked to me that his changes would be 
robust to backing out.  He could be asked about this.  
Again, I am *not* trying to advocate backing out.

> I note that the thread on scipy ended pretty quickly, so 
> I didn't get the impression there was a lot of resistance. 

I agree with this.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Bruce Southey]

Charles R Harris wrote:
>
>
> On Fri, May 9, 2008 at 8:51 AM, Bruce Southey <[EMAIL PROTECTED] 
> > wrote:
>
> Charles R Harris wrote:
> >
> >
> > On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant
> <[EMAIL PROTECTED] 
> > >> wrote:
> >
> >
> > Hi all,
> >
> > I'm having trouble emailing this list from work, so I'm using a
> > different email address.
> >
> > After Nathan Bell's recent complaints, I'm a bit more
> > uncomfortable with
> > the matrix change to scalar indexing.   It does and will
> break code in
> > possibly hard-to-track down ways.   Also, Nathan has been a
> *huge*
> > contributor to the Sparse matrix in scipy and so I value his
> opinion
> > about the NumPy matrix.  One of my goals is to have those
> two objects
> > work together a bit more seamlessly.
> >
> > So, I think we need to:
> >
> > 1) Add a warning to scalar access
> > 2) Back-out the change and fix all the places where NumPy
> assumes
> > incorrectly that the number of dimensions reduce on
> > PySequence_GetItem.
> >
> >
> > -1.
> >
> > That said, the basic mistake is probably making Matrix a subclass of
> > ndarray, as it fails the "is a" test. There really aren't that many
> > places where inheritance is the right choice and  numpy itself
> wasn't
> > designed as a base class: it lacks a specification of what functions
> > can be "virtual" and is probably too big.
> >
> > I vote that we bring Nathan into the conversation and see how
> upset he
> > really is. Speaking for myself, I sometimes get angry upfront when
> > specifications change unexpectedly underfoot but then settle
> down and
> > find that it isn't all that bad. Being caught by surprise is
> probably
> > half the problem.
> >
> > Chuck
> >
> >
> >
> 
> >
> > ___
> > Numpy-discussion mailing list
> > Numpy-discussion@scipy.org 
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> >
> Hi,
> +1
>
> The prime reason is not whether or not it is a bad/good idea but
> because
> the actual change was introduced so late in the development of
> 1.0.5/1.1
> process. A lesser reason is that gives people like Nathan time to
> change
> their code to match the pending release. Unfortunately the other
> problem
> with this change is that any user now has to be careful of which NumPy
> version is being used. The result is that backwards compatibility
> is now
> broken in what was originally going to be a minor release.
>
>
> Of course, if Nathan has already made the changes we will drive him 
> crazy if we back them out now ;) I note that the thread on scipy ended 
> pretty quickly, so I didn't get the impression there was a lot of 
> resistance.
>
Sure all the related threads ended abruptly perhaps related to the fact 
that Travis suggested the change :-)


Bruce

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Timothy Hochberg]

On Fri, May 9, 2008 at 6:43 AM, Travis Oliphant <[EMAIL PROTECTED]>
wrote:

>
> Hi all,
>
> I'm having trouble emailing this list from work, so I'm using a
> different email address.
>
> After Nathan Bell's recent complaints, I'm a bit more uncomfortable with
> the matrix change to scalar indexing.   It does and will break code in
> possibly hard-to-track down ways.   Also, Nathan has been a *huge*
> contributor to the Sparse matrix in scipy and so I value his opinion
> about the NumPy matrix.  One of my goals is to have those two objects
> work together a bit more seamlessly.
>
> So, I think we need to:
>
> 1) Add a warning to scalar access
> 2) Back-out the change and fix all the places where NumPy assumes
> incorrectly that the number of dimensions reduce on PySequence_GetItem.



+0

My personal opinion is that current matrix class is pretty useless and the
change won't help much from my point of view. My preference would be to
leave the matrix class alone, design a new matrix class, with a different
name, for 1.2 and then deprecate the old matrix class. Piecemeal fixing of
the matrix class is going to break someone's code and doesn't really get us
where we want to go.

Of course, since I think the matrix class is kind of useless, I'm not
terribly invested in this change one way or another.



>
>
> Opinions?
>
> -Travis
>
>
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
. __
. |-\
.
. [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jonathan Wright]

Timothy Hochberg wrote:
> +0
>
> My personal opinion is that current matrix class is pretty useless and 
> the change won't help much from my point of view. My preference would 
> be to leave the matrix class alone, design a new matrix class, with a 
> different name, for 1.2 and then deprecate the old matrix class
+1


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Charles R Harris]

On Fri, May 9, 2008 at 9:56 AM, Jonathan Wright <[EMAIL PROTECTED]> wrote:

> Timothy Hochberg wrote:
> > +0
> >
> > My personal opinion is that current matrix class is pretty useless and
> > the change won't help much from my point of view. My preference would
> > be to leave the matrix class alone, design a new matrix class, with a
> > different name, for 1.2 and then deprecate the old matrix class
> +1
>

The problem here is the workarounds in the numpy code, which we would have
to maintain. I am against messing with the numpy code just to accommodate a
matrix class that shouldn't have inherited from ndarray in the first place.
So I am OK with backing out the changes as long as we also leave all the
bugs in place.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Fri, May 9, 2008 at 9:07 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>
> Point of information: it looks like Nathan already made the
> needed fixes, and the changes made were in my opinion not at
> all obscure and indeed were rather minor.  (Which does not
> deny they were needed.)
>

That's correct, the necessary changes to scipy.sparse were not very substantial.

-- 
Nathan Bell [EMAIL PROTECTED]
http://graphics.cs.uiuc.edu/~wnbell/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Fri, May 9, 2008 at 10:28 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>
> Since I mentioned Nathan's changes, I wish to clarify
> something.  I have no idea what Nathan's views are, but as
> I recall them, it looked to me that his changes would be
> robust to backing out.

That should be true.

-- 
Nathan Bell [EMAIL PROTECTED]
http://graphics.cs.uiuc.edu/~wnbell/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Fri, May 9, 2008 at 9:56 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> Of course, if Nathan has already made the changes we will drive him crazy if
> we back them out now

This shouldn't be a problem, scipy.sparse should work with either

Thanks for your concern though :)

-- 
Nathan Bell [EMAIL PROTECTED]
http://graphics.cs.uiuc.edu/~wnbell/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Fri, 9 May 2008, Timothy Hochberg apparently wrote:
> I think the matrix class is kind of useless, 

In my field (economics), it has been a great way to 
introduce students to NumPy.  I suggest that this
reason alone makes it far from "useless".

I also personally find it convenient for linear algebra.
(I think you have stressed that this is just due to a
dearth of operators, but that is the current situation.)

Cheers,
Alan

PS In contrast to those supporting more ambitious and 
complex proposals, I think Travis's patch fixes almost 
everything that needs to be fixed.



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Fri, 9 May 2008, Charles R Harris apparently wrote:
> I am against messing with the numpy code just to 
> accommodate a matrix class that shouldn't have inherited 
> from ndarray in the first place.  So I am OK with backing 
> out the changes as long as we also leave all the bugs in 
> place. 

That's how we got here in the first place, I think.
Trading off problems in current behavior vs. the possibility 
that other code (like Nathan's) might rely on that bad behavior.
Uncomfortable either way.

One piece of good news: Nathan's fixes were easy,
so one way forward is not looking too rocky.

fwiw,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Fri, May 9, 2008 at 12:31 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>
> That's how we got here in the first place, I think.
> Trading off problems in current behavior vs. the possibility
> that other code (like Nathan's) might rely on that bad behavior.
> Uncomfortable either way.

We'll, I think we've established that the possibility of breaking
people's code is 1 :)

> One piece of good news: Nathan's fixes were easy,
> so one way forward is not looking too rocky.

True, but scipy.sparse makes fairly limited use of matrix and I have
386 unittests to tell me what broke.  End-users might spend
considerably longer sorting out the problem, particularly if they
don't know what they're looking for.  Personally, I would not have
thought a 1.0 -> 1.1 version bump would break something like this.
Yes, we can put caveats in the release notes, but how many
numpy.matrix users read those?

Some aspects of the change are still broken.  It's probably annoying
to end users when they pass a matrix into a function and get an
ndarray back out.  Now matrix indexing is itself guilty of this
offense.  Furthermore, some users probably *do* rely on the lack of
dimension reduction because that's one of the few differences between
the matrix and ndarray.

Alan, I don't fundamentally disagree with your positions on the
deficiencies/quirks of matrices in numpy.  However, it's completely
inappropriate to plug one hole while creating others, especially in a
minor release.   I suspect that if we surveyed end-users we'd find
that "my code still works" is a much higher priority than "A[0][0] now
does what I expect".

IMO scalar indexing should raise a warning (as you first suggested) in
the 1.1 release.

-- 
Nathan Bell [EMAIL PROTECTED]
http://graphics.cs.uiuc.edu/~wnbell/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Charles R Harris]

On Fri, May 9, 2008 at 10:06 AM, Charles R Harris <[EMAIL PROTECTED]>
wrote:

>
>
> On Fri, May 9, 2008 at 9:56 AM, Jonathan Wright <[EMAIL PROTECTED]> wrote:
>
>> Timothy Hochberg wrote:
>> > +0
>> >
>> > My personal opinion is that current matrix class is pretty useless and
>> > the change won't help much from my point of view. My preference would
>> > be to leave the matrix class alone, design a new matrix class, with a
>> > different name, for 1.2 and then deprecate the old matrix class
>> +1
>>
>
> The problem here is the workarounds in the numpy code, which we would have
> to maintain. I am against messing with the numpy code just to accommodate a
> matrix class that shouldn't have inherited from ndarray in the first place.
> So I am OK with backing out the changes as long as we also leave all the
> bugs in place.
>

So to start a different line here, what properties *should* a base class
have? I would posit that the scalar types,  strided memory,  ufuncs, and
broadcasting would be the fundamental properties. The strided memory and
ufuncs, and perhaps broadcasting, probably can't be directly used by sparse
arrays, so this may be too general already. Things like constructors (array,
matrix), display (print), and operator choices (+,-,*, indexing), should
not. The problem with operators is that we want Python to do the parsing and
want to use sequences and such. One possibility here is to provide separate
functions with different names to replace PySequence_GetItem and
PySequence_Length internally in numpy, that is, we no longer consider arrays
as nested Python sequences. Instead, we provide a standalone function to
translate nested sequences to arrays, which is pretty much what we have now.
So we don't just special case matrices, we special case arrays in general
and only use PySequence_GetItem internally for genuine Python sequences.
>From this common base we can then derive ndarray which defines __getitem__
to use the new functions and can also derive matrices which define
__getitem__ differently.

I'm just thinking out loud here where folks might notice to start a
different thread. This doesn't solve the problem of what matrices should be,
but it does remove the problem of decreasing dimensions.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Fri, 9 May 2008, Nathan Bell apparently wrote:
> I don't fundamentally disagree with your positions on the 
> deficiencies/quirks of matrices in numpy.  However, it's 
> completely inappropriate to plug one hole while creating 
> others

I think we have to be careful with that argument.
The relative size of holes can matter.

> especially in a minor release. 

That is a separate question, on which I am not expressing an 
opinion.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jarrod Millman]

Hello,

I have obviously decided to delay tagging 1.1.0 until we resolve this.

I didn't realize that numpy matrices were used in scipy or I would
have brought this up before, but whatever matrix change we make in 1.1
has to work with the scipy 0.6.  Unfortunately, I can't check myself
at the moment; but I should be able to look into it tomorrow.

Would someone please check that scipy 0.6 still works with the 1.1
branch?  And let me know ASAP.

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
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jarrod Millman]

On Fri, May 9, 2008 at 8:36 AM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> My personal opinion is that current matrix class is pretty useless and the
> change won't help much from my point of view. My preference would be to
> leave the matrix class alone, design a new matrix class, with a different
> name, for 1.2 and then deprecate the old matrix class. Piecemeal fixing of
> the matrix class is going to break someone's code and doesn't really get us
> where we want to go.

Sort of +1.

I am not a user of the numpy matrix, but I am increasingly feeling
that we should leave them alone for the 1.1 release.  This change was
more or less rushed through at the end of the 1.1 development cycle
due to both the feeling that there was an eminent and unique
opportunity for API breakage and a near universal agreement that the
current matrix behavior was less than ideal.

However, we will be releasing 1.2 in a few months and it will be
entirely possible to break the matrices API then if there is an
agreement that it still needs to be done.  It seems that the longer
this discussion has gone on, the more alternative "fixes" that are
proposed and discussed.  Basically almost everyone who joins the
discussion suggests yet a new fix.  Also not all the NumPy/SciPy core
developers have been following this discussion and I want to make sure
everyone has the opportunity to become engaged in this conversation
before we settle on even a minor change this late in the development
cycle.  Moreover, I think that given the numerous bug fixes that have
gone into this release, it would be a shame if this somewhat last
minute API break turns out to introduce even on new bug that we don't
notice before the release.

Finally, I would like to apologize for not proposing a more sensible
process earlier for introducing API breaking code (I am learning as I
go).  As we turn our attention to developing  1.2, I am going to
provide more formal phases to the development process.  Any code that
breaks API will be required to be introduced and committed during the
beginning of the development cycle.  And not in the very last phase of
the development cycle when we should be focused solely on critical
bugs, major regression, documentation, and extensive testing.

So unless there are major objections, I am going to back out the
matrices changes in the 1.1 branch.  I will leave whatever changes
have occurred in the trunk.  Sorry if you feel I am overstepping my
"authority".  If so, please let me know.  My goal is not to cut short
discussion so much as to move the 1.1.0 release forward, so that we
can get the numerous bug fixes and improvements to our users while
also letting the developers start working on the next release (1.2) as
soon as possible.

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
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Robert Kern]

On Sat, May 10, 2008 at 4:35 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:

> However, we will be releasing 1.2 in a few months and it will be
> entirely possible to break the matrices API then if there is an
> agreement that it still needs to be done.

Please, let's have a firm policy of having a DeprecationWarning for at
least one revision of 1.x before breaking something in 1.x+1.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jarrod Millman]

On Sat, May 10, 2008 at 2:47 AM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 10, 2008 at 4:35 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
>
>> However, we will be releasing 1.2 in a few months and it will be
>> entirely possible to break the matrices API then if there is an
>> agreement that it still needs to be done.
>
> Please, let's have a firm policy of having a DeprecationWarning for at
> least one revision of 1.x before breaking something in 1.x+1.

+1
I agree.  Let's pretend I said "... it will be entirely possible to a
DeprecationWarning for the matrices API with the 1.2 release and
switching to the a new API in 1.3 (if there is an agreement as to what
the new behavior should be before the 1.2 release) ...".

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Sat, 10 May 2008, Jarrod Millman wrote:
> unless there are major objections, I am going to back out 
> the matrices changes in the 1.1 branch. 

If these are backed out, will some kind of deprecation 
warning be added for scalar indexing, as Travis suggested?
Robert's request seems in accord with this.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Keith Goodman]

On Sat, May 10, 2008 at 8:08 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Sat, 10 May 2008, Jarrod Millman wrote:
>> unless there are major objections, I am going to back out
>> the matrices changes in the 1.1 branch.
>
> If these are backed out, will some kind of deprecation
> warning be added for scalar indexing, as Travis suggested?
> Robert's request seems in accord with this.

Shouldn't a deprecation warning explain what the future behavior will
be? Is there a firm consensus on what that behavior will be?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan McIntyre]

On Sat, May 10, 2008 at 11:14 AM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> Shouldn't a deprecation warning explain what the future behavior will
> be? Is there a firm consensus on what that behavior will be?

For what the opinion of an interested observer is worth: I honestly
can't tell whether there's a consensus or not.  If there is, I'm not
quite sure where I'd look to get the details of the 'official'
behavior (but that might just be due to my lack of familiarity with
the way things get documented for NumPy).
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

>> On Sat, 10 May 2008, Jarrod Millman wrote:
>>> unless there are major objections, I am going to back out 
>>> the matrices changes in the 1.1 branch. 

> On Sat, May 10, 2008 at 8:08 AM, Alan G Isaac 
> <[EMAIL PROTECTED]> wrote:
>> If these are backed out, will some kind of deprecation 
>> warning be added for scalar indexing, as Travis 
>> suggested?  Robert's request seems in accord with this. 

On Sat, 10 May 2008, Keith Goodman apparently wrote:
> Shouldn't a deprecation warning explain what the future 
> behavior will be?

I do not think so.  I think the warning should say:
"use x[0,:] instead of x[0] to return row 0 as a matrix."

> Is there a firm consensus on what that behavior will be?

My understanding of the plan:

- step 1: scalar indexing and iteration returns 1d 
  arrays.
- possible step 2: scalar indexing and iteration 
  return "oriented" 1d-array-like objects ("vectors")
  suitable for linear algebra.

Personally, I only care that step 1 is achieved.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Keith Goodman]

On Sat, May 10, 2008 at 9:24 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Sat, 10 May 2008, Keith Goodman apparently wrote:
>> Shouldn't a deprecation warning explain what the future
>> behavior will be?
>
> I do not think so.  I think the warning should say:
> "use x[0,:] instead of x[0] to return row 0 as a matrix."

That would confuse me. I would think it meant that I have to use
x[0,:] right now. Maybe you could add something that explains that
this is in the future? Something like: "In future versions x[0] will
not return row 0 as a matrix, but x[0,:] will continue to return a
matrix"?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jarrod Millman]

On Sat, May 10, 2008 at 8:14 AM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>> If these are backed out, will some kind of deprecation
>> warning be added for scalar indexing, as Travis suggested?
>> Robert's request seems in accord with this.
>
> Shouldn't a deprecation warning explain what the future behavior will
> be? Is there a firm consensus on what that behavior will be?

I agree that a deprecation warning needs to explain the future
behavior and don't believe we have agreed on what it should be yet.

I don't personally have an opinion on the what the new behavior should
be at this point.  But I don't think it makes sense to add deprecation
warnings at this point--unless we know exactly what it is that we will
be doing in the future.  So while it could be argued that it would be
useful to say "use x[0,:] instead of x[0] to return row 0 as a matrix"
in the 1.1 release, my sense is that we will still need to replace
that DeprecationWarning in 1.2 with a new DeprecationWarning saying
something like "in 1.3 x[0] will return  and if you want  you
will need to call x[0,:]".  I don't think we should have two different
DeprecationWarnings in back to back releases and believe that we
should wait to include the warning until we decide what the new
behavior will be in 1.2.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Anne Archibald]

2008/5/10 Jarrod Millman <[EMAIL PROTECTED]>:
> On Sat, May 10, 2008 at 8:14 AM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>>> If these are backed out, will some kind of deprecation
>>> warning be added for scalar indexing, as Travis suggested?
>>> Robert's request seems in accord with this.
>>
>> Shouldn't a deprecation warning explain what the future behavior will
>> be? Is there a firm consensus on what that behavior will be?
>
> I agree that a deprecation warning needs to explain the future
> behavior and don't believe we have agreed on what it should be yet.
>
> I don't personally have an opinion on the what the new behavior should
> be at this point.  But I don't think it makes sense to add deprecation
> warnings at this point--unless we know exactly what it is that we will
> be doing in the future.  So while it could be argued that it would be
> useful to say "use x[0,:] instead of x[0] to return row 0 as a matrix"
> in the 1.1 release, my sense is that we will still need to replace
> that DeprecationWarning in 1.2 with a new DeprecationWarning saying
> something like "in 1.3 x[0] will return  and if you want  you
> will need to call x[0,:]".  I don't think we should have two different
> DeprecationWarnings in back to back releases and believe that we
> should wait to include the warning until we decide what the new
> behavior will be in 1.2.

Regrettably I have to agree that we can't introduce a
DeprecationWarning until 1.2. I don't agree that x[0,:] should return
a matrix! It should be the one-dimensional object it looks like. See
Keith Goodman's recent message -
http://projects.scipy.org/pipermail/numpy-discussion/2008-May/033726.html
- for an example of why representing 1D objects as 2D objects is
trouble. I am of the opinion that matrix indexing should be identical
to array indexing, insofar as that is possible.

I don't expect my opinion to prevail, but the point is that we do not
even have enough consensus to agree on a recommendation to go in the
DeprecationWarning. Alas.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Sat, May 10, 2008 at 3:05 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
>
> I don't expect my opinion to prevail, but the point is that we do not
> even have enough consensus to agree on a recommendation to go in the
> DeprecationWarning. Alas.
>

Would you object to raising a general Warning with a message like the following?

"matrix indexing of the form x[0] is ambiguous, consider the explicit
format x[0,:]"


-- 
Nathan Bell [EMAIL PROTECTED]
http://graphics.cs.uiuc.edu/~wnbell/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Anne Archibald]

2008/5/10 Nathan Bell <[EMAIL PROTECTED]>:
> On Sat, May 10, 2008 at 3:05 PM, Anne Archibald
> <[EMAIL PROTECTED]> wrote:
>>
>> I don't expect my opinion to prevail, but the point is that we do not
>> even have enough consensus to agree on a recommendation to go in the
>> DeprecationWarning. Alas.
>
> Would you object to raising a general Warning with a message like the 
> following?
>
> "matrix indexing of the form x[0] is ambiguous, consider the explicit
> format x[0,:]"

Well, since I at least have proposed changing the latter as well, the
warning doesn't actually help with deprecation. It does reduce the
amount of beginner foot-shooting (as in x[0][0]), I guess, so I'm not
opposed to it.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Jarrod Millman]

On Sat, May 10, 2008 at 1:21 PM, Nathan Bell <[EMAIL PROTECTED]> wrote:
> Would you object to raising a general Warning with a message like the 
> following?
>
> "matrix indexing of the form x[0] is ambiguous, consider the explicit
> format x[0,:]"

-1
I am not certain that there is universal agreement as to what x[0] or
x[0,:] should return.  Moreover, I don't think the phrase "ambiguous"
is entirely correct.  My understanding is that x[0] has a specified
behavior at this point and that in a later release it will still have
a specified behavior.  But there is some discussion as to whether we
should change that specific behavior.  So it isn't that it is
ambiguous exactly, but that we may change its meaning.  I guess it
might be reasonable to say something like "the developers are
currently discussing changing the meaning of x[0] (and perhaps even
x[0,:]), but we haven't agreed on how, or even if, we will change it."
 [If we are going to say that, we might want to suggest that our users
consider using arrays--not that I am arguing for that :)]

I don't think it is worth focusing much more effort on trying to come
up with some language that we all agree on to indicate that we are
discussing changing this in the future.  We have made considerable
progress in preparing for 1.1.0; we have nearly doubled the number of
tests, fixed nearly 200 bugs, greatly improved the quality and
coverage of our documentation, vastly improved MaskedArrays, fixed the
histogram, etc.  I think it may be time to release what we have at
this point and start working on 1.2.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Timothy Hochberg]

On Sat, May 10, 2008 at 1:37 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:

> 2008/5/10 Nathan Bell <[EMAIL PROTECTED]>:
> > On Sat, May 10, 2008 at 3:05 PM, Anne Archibald
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> I don't expect my opinion to prevail, but the point is that we do not
> >> even have enough consensus to agree on a recommendation to go in the
> >> DeprecationWarning. Alas.
> >
> > Would you object to raising a general Warning with a message like the
> following?
> >
> > "matrix indexing of the form x[0] is ambiguous, consider the explicit
> > format x[0,:]"
>
> Well, since I at least have proposed changing the latter as well, the
> warning doesn't actually help with deprecation. It does reduce the
> amount of beginner foot-shooting (as in x[0][0]), I guess, so I'm not
> opposed to it.
>

Please, let's just leave the current matrix class alone. Any change
sufficient to make matrix not terrible, will break everyone's code. Instead,
the goal should be build a new matrix class (say newmatrix) where we can
start from scratch. We can build it and keep it alpha for a while so we can
break the interface as needed while we get experience with it and then,
maybe, transition matrix to oldmatrx and newmatrix to matrix over a couple
of releases. Or just choose a reasonable name for matrix to begin with
(ndmatrix?) and then deprecate the current matrix class when the new one is
fully baked.

Trying to slowly morph matrix into something usable is just going to break
code again and again and just be a giant headache in general.



-- 
. __
. |-\
.
. [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Keith Goodman]

On Sat, May 10, 2008 at 2:35 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> Please, let's just leave the current matrix class alone. Any change
> sufficient to make matrix not terrible, will break everyone's code. Instead,
> the goal should be build a new matrix class (say newmatrix) where we can
> start from scratch. We can build it and keep it alpha for a while so we can
> break the interface as needed while we get experience with it and then,
> maybe, transition matrix to oldmatrx and newmatrix to matrix over a couple
> of releases. Or just choose a reasonable name for matrix to begin with
> (ndmatrix?) and then deprecate the current matrix class when the new one is
> fully baked.
>
> Trying to slowly morph matrix into something usable is just going to break
> code again and again and just be a giant headache in general.

+1

That sounds ideal to me. What's the first step? A design spec on the wiki?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Anne Archibald]

2008/5/10 Timothy Hochberg <[EMAIL PROTECTED]>:
> On Sat, May 10, 2008 at 1:37 PM, Anne Archibald <[EMAIL PROTECTED]>
> wrote:
>>
>> 2008/5/10 Nathan Bell <[EMAIL PROTECTED]>:
>> > On Sat, May 10, 2008 at 3:05 PM, Anne Archibald
>> > <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I don't expect my opinion to prevail, but the point is that we do not
>> >> even have enough consensus to agree on a recommendation to go in the
>> >> DeprecationWarning. Alas.
>> >
>> > Would you object to raising a general Warning with a message like the
>> > following?
>> >
>> > "matrix indexing of the form x[0] is ambiguous, consider the explicit
>> > format x[0,:]"
>>
>> Well, since I at least have proposed changing the latter as well, the
>> warning doesn't actually help with deprecation. It does reduce the
>> amount of beginner foot-shooting (as in x[0][0]), I guess, so I'm not
>> opposed to it.
>
> Please, let's just leave the current matrix class alone. Any change
> sufficient to make matrix not terrible, will break everyone's code. Instead,
> the goal should be build a new matrix class (say newmatrix) where we can
> start from scratch. We can build it and keep it alpha for a while so we can
> break the interface as needed while we get experience with it and then,
> maybe, transition matrix to oldmatrx and newmatrix to matrix over a couple
> of releases. Or just choose a reasonable name for matrix to begin with
> (ndmatrix?) and then deprecate the current matrix class when the new one is
> fully baked.
>
> Trying to slowly morph matrix into something usable is just going to break
> code again and again and just be a giant headache in general.

+1

I think something along the lines of the Numerical Ruby code you
pointed to some time ago is a good idea, that is, an "array of
matrices" object and an "array of vectors" object. There will be
considerable challenges - distinguishing the two kinds of index
manipulations on arrays of matrices (those that transpose every matrix
in the array, for eample, and those that rearrange the array of
matrices). Since teaching is one of the main current applications of
matrices, these should be presented in as non-painful a way as
possible.

Anyway, I think I am in favour of returning the 1.1 matrix behaviour
to its 1.0 form and releasing the thing.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Gael Varoquaux]

On Fri, May 09, 2008 at 12:53:40PM -0500, Nathan Bell wrote:
> True, but scipy.sparse makes fairly limited use of matrix and I have
> 386 unittests to tell me what broke.  End-users might spend
> considerably longer sorting out the problem, particularly if they
> don't know what they're looking for.  Personally, I would not have
> thought a 1.0 -> 1.1 version bump would break something like this.
> Yes, we can put caveats in the release notes, but how many
> numpy.matrix users read those?

Exact. Don't break existing code, or users will hate you, and eventually
stop using your code. In real life, many of the domain-specific libraries
still use numeric or numarray. People like to write code, and forget
about it for 10 years. If you change APIs they cannot do this.

> Alan, I don't fundamentally disagree with your positions on the
> deficiencies/quirks of matrices in numpy.  However, it's completely
> inappropriate to plug one hole while creating others, especially in a
> minor release.   I suspect that if we surveyed end-users we'd find
> that "my code still works" is a much higher priority than "A[0][0] now
> does what I expect".

+1. Pluging one annoyance to create another one (IMHO worse), and in
addition breaking backward compatibility seems utterly wrong to me.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Alan G Isaac]

On Sun, 11 May 2008, Gael Varoquaux apparently wrote:
> Pluging one annoyance to create another one (IMHO worse), 
> and in addition breaking backward compatibility seems 
> utterly wrong to me. 

I'm a little puzzled by this phrasing.

As Anne pointed out, examples are accumulating that there is 
a *fundamental* problem with matrix handling of scalar 
indexing.  I agree with this.  It is not just an 
"annoyance".  It keeps affecting code that tries to handle 
both matrices and arrays in a generic way.

Your phrasing suggests that the only solution is to live 
with this forever, always cobbling new workarounds, unless 
backward compatability can be ensured for more sensible 
behavior, which it pretty clearly cannot.  Is that your 
current stance?

I suspect part of the problem is that "backward 
compatability" is being interpreted in terms of discoverable 
behavior, rather than in terms of documented behavior.

Alan

PS Earlier I thought you favored raising an error in 
response to scalar indexing of matrices...


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Gael Varoquaux]

On Sun, May 11, 2008 at 12:26:49PM -0400, Alan G Isaac wrote:
> As Anne pointed out, examples are accumulating that there is 
> a *fundamental* problem with matrix handling of scalar 
> indexing.  I agree with this.  It is not just an 
> "annoyance".  It keeps affecting code that tries to handle 
> both matrices and arrays in a generic way.

I don't care, personally. This is a problem. I agree with you. Breaking
existing code is a major disturbance. It as to be weighted with the
gains. The solution of adding another bug elsewhere to plug this problem
is not good to me. This is why I favor the proposal #1 on your list of
propsal http://www.scipy.org/MatrixIndexing , because it introduces the
minimal amount of changes to the interfaces.

> Your phrasing suggests that the only solution is to live 
> with this forever, always cobbling new workarounds, unless 
> backward compatability can be ensured for more sensible 
> behavior, which it pretty clearly cannot.  Is that your 
> current stance?

No, but I am pretty close to this.

> I suspect part of the problem is that "backward 
> compatability" is being interpreted in terms of discoverable 
> behavior, rather than in terms of documented behavior.

Not at all. It is to be interpreted in terms of "I have a few dozens kilolines 
of code left by a student who work with numpy 1.0, if I upgrade numpy,
will they still work?". I do realize the limits of freezing the behavior
of software: bugware. I am not for a complete freeze, I am for a very
well-thought move forward, that introduces a minimum of breakage.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Chris.Barker]

Could we add a "from __future__ import something" along with a 
deprecation warning?

This could be used for Tim's "new matrix" class, or any other API change.

-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

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Uncomfortable with matrix change

[Robert Kern]

On Mon, May 12, 2008 at 1:46 AM, Chris.Barker <[EMAIL PROTECTED]> wrote:
>
>  Could we add a "from __future__ import something" along with a
>  deprecation warning?

That's a Python language feature. It is not available to us.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion