headers
eric | 1 Jun 2002 21:13

bug in negative stride indexing for empty arrays

Hi,

I just ran across a situation where reversing an empty array using a negative
stride populates it with a new element.  I'm betting this isn't the intended
behavior.

An example code snippet is below.

eric

C:\home\ej\wrk\chaco>python
Python 2.1.3 (#35, Apr  8 2002, 17:47:50) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from Numeric import *
>>> import Numeric
>>> Numeric.__version__
'21.0'
>>> a = array(())
>>> a
zeros((0,), 'l')
>>> len(a)
0
>>> b = a[::-1]
>>> len(b)
1
>>> b
array([0])

--
Eric Jones <eric at enthought.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
eric | 1 Jun 2002 21:40

Re: Bug: extremely misleading array behavior

----- Original Message -----
From: "Konrad Hinsen" <hinsen <at> cnrs-orleans.fr>
To: "Pearu Peterson" <pearu <at> cens.ioc.ee>
Cc: <numpy-discussion <at> lists.sourceforge.net>
Sent: Wednesday, May 29, 2002 4:08 AM
Subject: Re: [Numpy-discussion] Bug: extremely misleading array behavior

> Pearu Peterson <pearu <at> cens.ioc.ee> writes:
>
> > an array with 0 rank. It seems that the Numeric documentation is missing
> > (though, I didn't look too hard) the following rules of thumb:
> >
> >   If `a' is rank 1 array, then a[i] is Python scalar or object. [MISSING]
>
> Or rather:
>
> - If `a' is rank 1 array with elements of type Int, Float, or Complex,
>   then a[i] is Python scalar or object. [MISSING]
>
> - If `a' is rank 1 array with elements of type Int16, Int32, Float32, or
>   Complex32, then a[i] is a rank 0 array. [MISSING]
>
> - If `a' is rank > 1 array, then a[i] is a sub-array a[i,...]
>
> The rank-0 arrays are the #1 question topic for users of my netCDF
> interface (for portability reasons, netCDF integer arrays map to
> Int32, not Int, so scalar integers read from a netCDF array are always
> rank-0 arrays), and almost everybody initially claims that it's a bug,
> so some education seems necessary.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jake Edge | 3 Jun 2002 16:20

no 3 arg multiply in MA?

I was converting a program written for Numeric to use masked arrays and 
I ran into a problem with multiply ... it would appear that there is no
3 argument version for MA?  i.e.

a = array([1, 2, 3])
multiply(a,a,a)

works fine to square the array using Numeric, but i get an exception:

TypeError: __call__() takes exactly 3 arguments (4 given)

when doing it using MA ...

it seems clear that that is the problem, is it an oversight or just as yet
unimplemented or am I missing something?

thanks!

jake
Permalink | Reply | 0 comments |
headers
Jake Edge | 3 Jun 2002 16:40

some casting oddness?

I am using both MA and Numeric in a program that I am writing and ran into
some typecasting oddness (at least I thought it was odd).  When using only
Numeric, adding an array of typecode 'l' and one of typecode '1' produces
an array of typecode 'l' whereas using an MA derived array of typecode '1'
added to a Numeric array of typecode 'l' produces an array of typecode '1'.
Sorry if that is a bit dense, the upshot is that mixing the two causes the
output to be the _smaller_ of the two types (Int8 == '1') rather than the
larger (Int == 'l') as I would expect ... below is some code that reproduces
the problem (it may look contrived (and is), but it comes from the guts of
some code I have been playing with):

#!/usr/bin/env python

from Numeric import *
import MA

a = zeros((10,))
print a.typecode()
b = MA.ones((10,),Int8)
b = MA.masked_where(MA.equal(b,1),b,0)
print b.typecode()
print b.mask().typecode()
z = ones((10,),Int8)
print z.typecode()
c = add(a,b.mask())
print c.typecode()
d = add(a,z)
print d.typecode()

I get output like:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Konrad Hinsen | 3 Jun 2002 18:30
Picon
Favicon

Re: Bug: extremely misleading array behavior

> I don't think education is the answer here. We need to change
> Numeric to have uniform behavior across all typecodes.

I agree that this would be the better solution. But until this is
done...

> Having alternative behaviors for indexing based on the typecode can
> lead to very difficult to find bugs. Generic routines meant to work

The differences are not that important, in most circumstances rank-0
arrays and scalars behave in the same way. The problems occur mostly
with code that does explicit type checking.

The best solution, in my opinion, is to provide scalar objects
corresponding to low-precision ints and floats, as part of NumPy.

Konrad.
--

-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen <at> cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Paul F Dubois | 3 Jun 2002 18:54

RE: Bug: extremely misleading array behavior

Konrad said:
> 
> The best solution, in my opinion, is to provide scalar 
> objects corresponding to low-precision ints and floats, as 
> part of NumPy.
> 
> Konrad.

One of the thoughts I had in mind for the "kinds" proposal was to
support this. I was going to do the float32 object as part of it as a
demo of how it would work. So I got out the float object from Python,
figuring I would just change a few types et voila. Not. It is very hard
to understand, and I don't even understand the reasons it is hard to
understand. Perhaps a young person with a high tolerance for pain would
look at this?
Permalink | Reply | 1 comment |
headers
Travis Oliphant | 3 Jun 2002 22:02
Picon

RE: Bug: extremely misleading array behavior

On Mon, 2002-06-03 at 10:54, Paul F Dubois wrote:
> 
> Konrad said:
> > 
> > The best solution, in my opinion, is to provide scalar 
> > objects corresponding to low-precision ints and floats, as 
> > part of NumPy.
> > 
> > Konrad.
>

This seems like a good idea.  It's been an old source of confusion.

On a related note, how does the community feel about retrofitting
Numeric with unsigned shorts and unsigned ints.  I've got the code to do
it already written.

-Travis
Permalink | Reply | 0 comments |
headers
Travis Oliphant | 4 Jun 2002 08:39
Picon

Unsigned shorts and ints

I would like to update the Numeric CVS tree to include support for
unsigned shorts and ints.

Making the transition will cause some difficulty with binary extensions
as these will need to be recompiled with the new Numeric.

As a result, I propose that a new release of Numeric be posted (to
include the recent bug fixes), and then the changes made for inclusion
in the next version number of Numeric.  

Comments?

-Travis
Permalink | Reply | 0 comments |
headers
Perry Greenfield | 4 Jun 2002 23:17

FW: Bug: extremely misleading array behavior

<Konrad Hinsen wrote>
  <Eric Jones wrote>
> > I don't think education is the answer here. We need to change
> > Numeric to have uniform behavior across all typecodes.
> 
> I agree that this would be the better solution. But until this is
> done...
> 
> > Having alternative behaviors for indexing based on the typecode can
> > lead to very difficult to find bugs. Generic routines meant to work
> 
> The differences are not that important, in most circumstances rank-0
> arrays and scalars behave in the same way. The problems occur mostly
> with code that does explicit type checking.
> 
> The best solution, in my opinion, is to provide scalar objects
> corresponding to low-precision ints and floats, as part of NumPy.
> 
There is another approach that I think is more sensible.
From what I can tell, the driving force behind rank-0 arrays
as scalars are the Numeric coercion rules. One needs to retain
the 'lesser' integer and float types so that operations with 
these psuedo-scalars and other arrays does not coerce arrays to
a higher type than would have been done when using the nearest
equivalent of Python scalars (if there is some other reason, I'd
like to know). For example if a and b are Int16 1-d arrays, if
indexing an element out of them produced a Python integer value
then 

a[0]*b becomes an Int32 (or even Int64 on some platforms?) array.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perry Greenfield | 6 Jun 2002 22:29

RE: FW: Bug: extremely misleading array behavior

[I thought I replied yesterday, but somehow that apparently vanished.]

<Konrad Hinsen writes>: 
> "Perry Greenfield" <perry <at> stsci.edu> writes:
> 
> > Numarray has different coercion rules so that this doesn't
> > happen. Thus one doesn't need c[1,1] to give a rank-0 array.
> 
> What are those coercion rules?
> 
For binary operations between a Python scalar and array, there is
no coercion performed on the array type if the scalar is of the
same kind as the array (but not same size or precision). For example
(assuming ints happen to be 32 bit in this case)

Python Int (Int32) * Int16 array --> Int16 array
Python Float (Float64) * Float32 array --> Float32 array. 

But if the Python scalar is of a higher kind, e.g., Python float
scalar with Int array, then the array is coerced to the corresponding
type of the Python scalar.

Python Float (Float64) * Int16 array --> Float64 array.
Python Complex (Complex64) * Float32 array --> Complex64 array. 

Numarray basically has the same coercion rules as Numeric when two
arrays are involved (there are some extra twists such as:

UInt16 array * Int16 array --> Int32 array
(Continue reading)

Permalink | Reply | 45 comments |

Gmane