[Numpy-discussion] Possible bug in numpy.trace()
It appears that something peculiar is going on with the numpy function trace(). The docs say that trace(A,...) is identical to A.trace(...). Here is a test: A = arange(8).reshape((2,2,2)) A.trace(0,1,2) #[Out]# array([ 3, 11]) # which is correct trace(A,0,1,2) #[Out]# array([6, 8]) #which is wrong #Since trace() is computed by summing the result of diagonal() A.diagonal(0,1,2) #[Out]# array([[0, 3], #[Out]#[4, 7]]) #which is correct diagonal(A,0,1,2) #[Out]# array([[0, 3], #[Out]#[4, 7]]) #which is the same correct result A.trace(0,0,1) #[Out]# array([6, 8]) #this is the erroneous answer we found earlier for trace(A,0,1,2) -- Donald R. Fredkin [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] APL2007 Update
APL 2007 in Montreal (only 2 1/2 weeks away, Oct 20-22). Summary program information is now available on the APL2007 home page http://www.sigapl.org/apl2007.html with a link to the comprehensive program description at http://www.sigapl.org/apl2007-program.html#a2 Registration for APL2007 is at http://www.regmaster.com/conf/oopsla2007.html ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
To help me understand, might someone offer some examples of NumPy names that really should be changed? Thank you, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote: > > On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote: > > > > >> 3) Greater time should be provided to accommodate the transition. For > >> example, there should not be deprecation warnings in the first > >> version that this API appears in. The first release of this should > >> not lead to nuisance messages for those that have other software that > >> depends on this. (A tool that allows conditional messages would be > >> good, but the default should be no message). The next release, sure. > >> As a result, it means that the old API can't be removed until at > >> least two releases after that. > > > > I am not sure I agree with this. For example, I think it would be > > acceptable for NumPy 1.1.0 to have deprecation warning about changed > > APIs. Perhaps you were saying that NumPy 1.0.4 could use the new > > class names in addition to the old names without complaint. That > > sounds reasonable to me. Then when NumPy 1.1.0 comes out the old > > style names would raise deprecation warnings. > > > The situation I'm trying to avoid is a too tight coupling between > numpy changes and client applications that use numpy. Suppose we > distribute an application that uses numpy. We could make the changes > to our application before the api-change release comes out (from svn) > and then when we release our new version (very soon after the api- > changed numpy comes out) we effectively force all of our users to > update immediately. The problem is that they may not want to update > on our schedule. They become annoyed at us. > > So we take the other tack, we wait for a while before changing our > code to require the new numpy. This give the user community time to > switch their stuff too. But, now our code generates annoying > deprecation warnings that are useless to the people we distribute > applications to if they update to the new numpy before we do. Here's > where I display some ignorance. If the warnings use the standard lib > warning module, I'm guessing that we can add warnings filters to > suppress any warnings that arise from our code (but not having much > experience with it, it isn't clear to me whether the filter > suppresses all warnings arising from numpy or whether one can > suppress only those associated with ones that are from the > applications use). But it's good to clarify this point. If they are > present by default, an application needs to be able to suppress them. > > > >> 5) In my humble opinion, we would be nuts--absolutely nuts--to change > >> either the type classes or the factory functions. This would be > >> foolish consistency at it's worst. We *just* went through the > >> exercise of changing Int32 to int32 and so forth and we would have to > >> change back again? This cannot be seriously considered. > > > > I think that the general consensus is that we should keep int32, > > rather than switch to Int32. > > That's good. But what about array(), zeros(), ones(), arange(), etc.? > Just to express my worries: I hope that numpy stays "easily typable" as a numerical and interactive (!) environment. What I'm trying to say: IMHO, "arange" should stay lower case, like "range", even if it might be (internally) implemented as a class. Similarly, many functions/objects/classes have a functional "feeling" to them, even tough they be implemented as classes. My 2 cents. -Sebastian Haase ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote: > >> 3) Greater time should be provided to accommodate the transition. For >> example, there should not be deprecation warnings in the first >> version that this API appears in. The first release of this should >> not lead to nuisance messages for those that have other software that >> depends on this. (A tool that allows conditional messages would be >> good, but the default should be no message). The next release, sure. >> As a result, it means that the old API can't be removed until at >> least two releases after that. > > I am not sure I agree with this. For example, I think it would be > acceptable for NumPy 1.1.0 to have deprecation warning about changed > APIs. Perhaps you were saying that NumPy 1.0.4 could use the new > class names in addition to the old names without complaint. That > sounds reasonable to me. Then when NumPy 1.1.0 comes out the old > style names would raise deprecation warnings. > The situation I'm trying to avoid is a too tight coupling between numpy changes and client applications that use numpy. Suppose we distribute an application that uses numpy. We could make the changes to our application before the api-change release comes out (from svn) and then when we release our new version (very soon after the api- changed numpy comes out) we effectively force all of our users to update immediately. The problem is that they may not want to update on our schedule. They become annoyed at us. So we take the other tack, we wait for a while before changing our code to require the new numpy. This give the user community time to switch their stuff too. But, now our code generates annoying deprecation warnings that are useless to the people we distribute applications to if they update to the new numpy before we do. Here's where I display some ignorance. If the warnings use the standard lib warning module, I'm guessing that we can add warnings filters to suppress any warnings that arise from our code (but not having much experience with it, it isn't clear to me whether the filter suppresses all warnings arising from numpy or whether one can suppress only those associated with ones that are from the applications use). But it's good to clarify this point. If they are present by default, an application needs to be able to suppress them. >> 5) In my humble opinion, we would be nuts--absolutely nuts--to change >> either the type classes or the factory functions. This would be >> foolish consistency at it's worst. We *just* went through the >> exercise of changing Int32 to int32 and so forth and we would have to >> change back again? This cannot be seriously considered. > > I think that the general consensus is that we should keep int32, > rather than switch to Int32. That's good. But what about array(), zeros(), ones(), arange(), etc.? Perry ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
On Wed, Oct 03, 2007 at 01:50:01PM -0400, Perry Greenfield wrote:
> > Let me rephrase: we cannot change the API until 1.1, unless this is
> > seen as a bug. To which other API changes are you referring? The
> > style changes is a different matter entirely.
>
> The recent numpy and scipy threads on "adopting Python Style Guide
> for classes". If this is what you mean by style changes and it ends
> up changing array to Array and int32 to Int32, it's not just a style
> change, it will break lots of code ("Since it should effect the user
> API..."). These are API changes even if you consider case of the
> class name just style.
Don't worry, nothing is being rushed through. Only internal
representations are currently being changed (e.g. unit tests). No
changes to the API will be made until 1.1, and then only after the
discussion is over.
I think your quote above refers to the e-mail Jarrod Millman wrote,
but that was simply a typo, and should have read "since it shouldn't
affect the user API".
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
On 10/3/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote: > As I understand it, the whole point of PEP-357 was to allow the coercion of > int-like things (numpy.int32 say, or your own private integerish class) to > be used as indices without also allowing things that aren't integers, but > that can be coerced to integers (floats for instance) to slip through. So > yes, I'd say this is a bug. Probably someplace that should be using > __index__ or the C equivalent is still using __int__, but I haven't had time > to look. It seems like a bug to me as well. > On the other hand, this may well be a bug that people rely on and it's not > doing drastic immediate harm. So, while I think it should get fixed > eventually, it's probably fine to wait till 1.1 or whenever the next > convenient time is. I don't know that it is essential to fix in the 1.0.x series, but 1.1 is still several months away. And the longer this "bug" is out there, the greater the chance that people will write code that depends on it. So I would tentatively vote to fix it sooner rather than later. -- 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] [SciPy-dev] adopting Python Style Guide for classes
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote: > 2) API changes should only be made in major releases, not minor > releases (IMHO). +1 > 3) Greater time should be provided to accommodate the transition. For > example, there should not be deprecation warnings in the first > version that this API appears in. The first release of this should > not lead to nuisance messages for those that have other software that > depends on this. (A tool that allows conditional messages would be > good, but the default should be no message). The next release, sure. > As a result, it means that the old API can't be removed until at > least two releases after that. I am not sure I agree with this. For example, I think it would be acceptable for NumPy 1.1.0 to have deprecation warning about changed APIs. Perhaps you were saying that NumPy 1.0.4 could use the new class names in addition to the old names without complaint. That sounds reasonable to me. Then when NumPy 1.1.0 comes out the old style names would raise deprecation warnings. > 4) More information should be provided as to what actually will > change in the public interface. I suspect that it isn't obvious to > many what will change. From the mailing list discussions there > doesn't even seem to be consensus on the factory functions or type > objects (more on these later). Many of the remaining objects are > probably used internally (essentially private) and will affect few > outside of the numpy developers. Since users typically deal mostly > with factory functions, and other functions, they may not deal with > classes much (outside of types). So listing the public classes so > affected will help people understand what changes typical users will > see, and what changes advanced users will see. While this is > annoying, I think someone needs to write up an explicit list of those > public classes that will be changed (and those that won't) so we all > know what we will face. It may be a very small list and thus > alleviate concern about the process. It may show some surprises that > people hadn't thought about. Not doing this before making the changes > seems very unwise. As long as we agree in principle how we want classes named, I think there is little need to rush to change existing class names. > 5) In my humble opinion, we would be nuts--absolutely nuts--to change > either the type classes or the factory functions. This would be > foolish consistency at it's worst. We *just* went through the > exercise of changing Int32 to int32 and so forth and we would have to > change back again? This cannot be seriously considered. I think that the general consensus is that we should keep int32, rather than switch to Int32. -- 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] indexing bug?
Timothy Hochberg wrote:
> As I understand it, the whole point of PEP-357 was to allow the coercion
> of int-like things (numpy.int32 say, or your own private integerish
> class) to be used as indices without also allowing things that aren't
> integers, but that can be coerced to integers (floats for instance) to
> slip through. So yes, I'd say this is a bug. Probably someplace that
> should be using __index__ or the C equivalent is still using __int__,
> but I haven't had time to look.
I believe the problem is in numpy/core/src/arrayobject.c:
2635 static PyObject *
2636 array_subscript_simple(PyArrayObject *self, PyObject *op)
2637 {
2638 intp dimensions[MAX_DIMS], strides[MAX_DIMS];
2639 intp offset;
2640 int nd;
2641 PyArrayObject *other;
2642 intp value;
2643
2644 value = PyArray_PyIntAsIntp(op);
--
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] indexing bug?
On 10/3/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > > Stefan van der Walt wrote: > >> The current behavior is consistent and well > >>> defined: > >>> a[x] == a[int(x)] > > This is all possible because of PEP 357: I think that the current behavior has always been possible; arbitrary objects can be passed as indices and coercing to int was always possible. http://www.python.org/dev/peps/pep-0357/ > > However, when I read this from the PEP: > > """ > It is not possible to use the nb_int (and __int__ special method) > for this purpose because that method is used to *coerce* objects > to integers. It would be inappropriate to allow every object that > can be coerced to an integer to be used as an integer everywhere > Python expects a true integer. For example, if __int__ were used > to convert an object to an integer in slicing, then float objects > would be allowed in slicing and x[3.2:5.8] would not raise an error > as it should. > """ > > It seems pretty clear that only integer types were intended to by used > as indexes. Does that make this a bug? I'll defer that to others more in > the know than I. As I understand it, the whole point of PEP-357 was to allow the coercion of int-like things (numpy.int32 say, or your own private integerish class) to be used as indices without also allowing things that aren't integers, but that can be coerced to integers (floats for instance) to slip through. So yes, I'd say this is a bug. Probably someplace that should be using __index__ or the C equivalent is still using __int__, but I haven't had time to look. On the other hand, this may well be a bug that people rely on and it's not doing drastic immediate harm. So, while I think it should get fixed eventually, it's probably fine to wait till 1.1 or whenever the next convenient time is. -- . __ . |-\ . . [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
Stefan van der Walt wrote: >> The current behavior is consistent and well >>> defined: >>> a[x] == a[int(x)] This is all possible because of PEP 357: http://www.python.org/dev/peps/pep-0357/ However, when I read this from the PEP: """ It is not possible to use the nb_int (and __int__ special method) for this purpose because that method is used to *coerce* objects to integers. It would be inappropriate to allow every object that can be coerced to an integer to be used as an integer everywhere Python expects a true integer. For example, if __int__ were used to convert an object to an integer in slicing, then float objects would be allowed in slicing and x[3.2:5.8] would not raise an error as it should. """ It seems pretty clear that only integer types were intended to by used as indexes. Does that make this a bug? I'll defer that to others more in the know than I. -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] indexing bug?
On Oct 3, 2007, at 1:35 PM, Stefan van der Walt wrote:
>
>>> We certainly can't change it now (just imagine all the code out
>>> there
>>> that will break); but I personally don't think it is a big problem.
>>>
>> I disagree. If people are willing to change the Class API of numpy
>> to be
>> consistent with Python, they certainly should be willing to change
>> this.
>> This behavior is new with numpy, so there should not be a lot of
>> code that
>> depends on it (and shame on those that do :-).
>
> Let me rephrase: we cannot change the API until 1.1, unless this is
> seen as a bug. To which other API changes are you referring? The
> style changes is a different matter entirely.
The recent numpy and scipy threads on "adopting Python Style Guide
for classes". If this is what you mean by style changes and it ends
up changing array to Array and int32 to Int32, it's not just a style
change, it will break lots of code ("Since it should effect the user
API..."). These are API changes even if you consider case of the
class name just style.
Perry Greenfield
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
On Wed, Oct 03, 2007 at 11:12:07AM -0400, Perry Greenfield wrote: > > On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote: > >> On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote: >>> This should return an error and not silently truncate to int. >> >> Why do you say that? The current behaviour is consistent and well >> defined: >> >> a[x] == a[int(x)] >> > I disagree. It is neither consistent nor well defined. It works for other objects too: class MyIndex(object): def __int__(self): return 1 m = M() x = N.array([1,2,3] x[m] == x[1] > It is not consistent with Python list indexing behavior. Neither are most other forms of ndarray indexing: x = [1,2,3] x[[1,2]] yields an error. > It is not consistent with numpy behavior: > > >>> x = arange(10) > >>> x[array(2.99)] > > raises an exception That seems to be an exception to the rule. I agree that both x[2.99] and x[array(2.99)] should behave the same way. >> We certainly can't change it now (just imagine all the code out there >> that will break); but I personally don't think it is a big problem. >> > I disagree. If people are willing to change the Class API of numpy to be > consistent with Python, they certainly should be willing to change this. > This behavior is new with numpy, so there should not be a lot of code that > depends on it (and shame on those that do :-). Let me rephrase: we cannot change the API until 1.1, unless this is seen as a bug. To which other API changes are you referring? The style changes is a different matter entirely. My point was that the current behaviour is easy to predict, but I am not especially partial on the matter. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] boolean matrix bug?
Shouldn't x**0 be boolean for a boolean matrix?
Cheers,
Alan Isaac
>>> import numpy
>>> numpy.__version__
'1.0.3.1'
>>> x = numpy.mat('1 1;1 0',dtype='bool')
>>> x**0
matrix([[ 1., 0.],
[ 0., 1.]])
>>> x**1
matrix([[ True, True],
[ True, False]], dtype=bool)
>>> x**2
matrix([[ True, True],
[ True, True]], dtype=bool)
>>>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
To follow on to my previous posting on this topic given Robert's response. As I said previously, I was never strongly committed to one approach or the other. But since the v1 release has been made, I think more care needs to be given to consideration of proposals like this before actually charging off to make the changes. 1) Even though Robert is speaking for Travis, I think given Travis's role in numpy, it is important for Travis to speak directly to this when he gets the chance. 2) API changes should only be made in major releases, not minor releases (IMHO). 3) Greater time should be provided to accommodate the transition. For example, there should not be deprecation warnings in the first version that this API appears in. The first release of this should not lead to nuisance messages for those that have other software that depends on this. (A tool that allows conditional messages would be good, but the default should be no message). The next release, sure. As a result, it means that the old API can't be removed until at least two releases after that. 4) More information should be provided as to what actually will change in the public interface. I suspect that it isn't obvious to many what will change. From the mailing list discussions there doesn't even seem to be consensus on the factory functions or type objects (more on these later). Many of the remaining objects are probably used internally (essentially private) and will affect few outside of the numpy developers. Since users typically deal mostly with factory functions, and other functions, they may not deal with classes much (outside of types). So listing the public classes so affected will help people understand what changes typical users will see, and what changes advanced users will see. While this is annoying, I think someone needs to write up an explicit list of those public classes that will be changed (and those that won't) so we all know what we will face. It may be a very small list and thus alleviate concern about the process. It may show some surprises that people hadn't thought about. Not doing this before making the changes seems very unwise. 5) In my humble opinion, we would be nuts--absolutely nuts--to change either the type classes or the factory functions. This would be foolish consistency at it's worst. We *just* went through the exercise of changing Int32 to int32 and so forth and we would have to change back again? This cannot be seriously considered. Perry Greenfield On Oct 2, 2007, at 1:24 PM, Jarrod Millman wrote: > Hello, > > For those of you not on the Numpy developer's list, we have been > talking about adopting the Python class naming convention to conform > with Guido's style guide as closely as possible: > http://www.python.org/dev/peps/pep-0008/ > According to Guido, class names should use the CapWords convention. > Most Python projects (eg, ETS, matploltlib) adhere to the Python > naming conventions and it is confusing that NumPy and SciPy don't. > > Currently, both NumPy and SciPy use either lower_underscore_separated > or CapWords for class names. > > NumPy > == > $ grep -r '^class [A-Z]' --include "*.py" * | wc -l > 1014 > $ grep -r '^class' --include "*.py" * | grep -v 'class [A-Z]' | wc -l > 207 > > SciPy > = > $ grep -r '^class [A-Z]' --include "*.py" * | wc -l > 587 > $ grep -r '^class' --include "*.py" * | grep -v 'class [A-Z]' | wc -l > 565 > > So far, there is Universal support for the basic idea of conforming to > the Python Style Guide. Since it should effect the user API, we have > already updated the TestCase classes. First, we checked in a change > to allow TestCase classes to be prefixed with > either 'test' or 'Test': > http://projects.scipy.org/scipy/numpy/changeset/4144 > Then, we updated both SciPy and NumPy to use CapWords for TestCase > classes: > http://projects.scipy.org/scipy/numpy/changeset/4151 > http://projects.scipy.org/scipy/scipy/changeset/3388 > In order to run the SciPy tests on the trunk you will need to install > NumPy from svn revision 4144 or greater. Before SciPy 0.7.0 is > released, we will release NumPy 1.0.4. > > Also, if you are adding a new class to NumPy or SciPy, please use > CapWords. Now we need to decide what to do about the remaining > lower_underscore_separated class names. Obviously, it is important > that we are careful to not break a lot of code just to bring our class > names up to standards. > > Cheers, > > -- > Jarrod Millman > Computational Infrastructure for Research Labs > 10 Giannini Hall, UC Berkeley > phone: 510.643.4014 > http://cirl.berkeley.edu/ > ___ > Scipy-dev mailing list > [EMAIL PROTECTED] > http://projects.scipy.org/mailman/listinfo/scipy-dev ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote: > > > On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote: > > > On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote: > >> This should return an error and not silently truncate to int. > > > > Why do you say that? The current behaviour is consistent and well > > defined: > > > > a[x] == a[int(x)] > > > I disagree. It is neither consistent nor well defined. > > It is not consistent with Python list indexing behavior. > > It is not consistent with numpy behavior: > > >>> x = arange(10) > >>> x[array(2.99)] > > raises an exception > > It didn't work in Numeric > It didn't work in numarray > > > We certainly can't change it now (just imagine all the code out there > > that will break); but I personally don't think it is a big problem. > > > I disagree. If people are willing to change the Class API of numpy to > be consistent with Python, they certainly should be willing to change > this. This behavior is new with numpy, so there should not be a lot > of code that depends on it (and shame on those that do :-). > > > On a somewhat related note, you may also be interested in the PEP at > > > > http://docs.python.org/whatsnew/pep-357.html > > > I believe that this PEP is irrelevant. It's purpose is to allow numpy > rank-0 arrays (what numpy returns on indexing single values in > arrays) to be used as an index in Python lists. It does not suggest > that float values should be used as indices for sequences. It does > provide a mechanism so that numpy rank-0 float arrays could be used > as indices to lists, but doesn't mean that they should. And > currently, they don't work as indices to lists (try it). > > So I can't see any reason not to treat the current behavior as > undesirable. It is not long standing (it wasn't available in numpy, > and only in odd ways in numarray--and it was a bug there [I feel I > can say that without contradiction :-)]. Now that the compatibility > can of worms is open, fixing this is a small thing compared to the > other issue being raised. I agree that this should be changed, and the sooner the better. Look at how many problems arange with float arguments causes, and the often expressed wish that it had never allowed floats in the first place. I suspect using floats as indexes is almost always a bug, and where it isn't the code would be much clearer if the conversion to integer was made explicit. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] indexing bug?
On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote: > On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote: >> This should return an error and not silently truncate to int. > > Why do you say that? The current behaviour is consistent and well > defined: > > a[x] == a[int(x)] > I disagree. It is neither consistent nor well defined. It is not consistent with Python list indexing behavior. It is not consistent with numpy behavior: >>> x = arange(10) >>> x[array(2.99)] raises an exception It didn't work in Numeric It didn't work in numarray > We certainly can't change it now (just imagine all the code out there > that will break); but I personally don't think it is a big problem. > I disagree. If people are willing to change the Class API of numpy to be consistent with Python, they certainly should be willing to change this. This behavior is new with numpy, so there should not be a lot of code that depends on it (and shame on those that do :-). > On a somewhat related note, you may also be interested in the PEP at > > http://docs.python.org/whatsnew/pep-357.html > I believe that this PEP is irrelevant. It's purpose is to allow numpy rank-0 arrays (what numpy returns on indexing single values in arrays) to be used as an index in Python lists. It does not suggest that float values should be used as indices for sequences. It does provide a mechanism so that numpy rank-0 float arrays could be used as indices to lists, but doesn't mean that they should. And currently, they don't work as indices to lists (try it). So I can't see any reason not to treat the current behavior as undesirable. It is not long standing (it wasn't available in numpy, and only in odd ways in numarray--and it was a bug there [I feel I can say that without contradiction :-)]. Now that the compatibility can of worms is open, fixing this is a small thing compared to the other issue being raised. Perry Greenfield ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
