numpy-discussion

[Numpy-discussion] bug?

[Peter V. <ve...@em...>]

Consider conversion of a slice using the astype() method:

>>> a = array([[1,2],[3,4]])
>>> b = a[1, ...]
>>> print b
[3 4]

Conversion using the astype() method goes wrong:

>>> print b.astype(Float32)
[ 1.  2.]

This fixes it:

>>> print b.copy().astype(Float32)
[ 3.  4.]

A bug?

Cheers, Peter

-- 
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

[Numpy-discussion] bug?

[<ve...@em...>]

possible bug? 
 
>>> a = array([[[1, 1], [0, 1]]]) 
>>> print logical_or.reduce(a, 0) 
[[1 0] 
 [1 1]] 
 
should be: 
 
>>> print a[0, ...] 
[[1 1] 
 [0 1]] 
 
Cheers, Peter 
-- 
Dr. Peter J. Verveer 
Cell Biology and Cell Biophysics Programme 
EMBL 
Meyerhofstrasse 1 
D-69117 Heidelberg 
Germany 
Tel. : +49 6221 387245 
Fax  : +49 6221 387242 
 

[Numpy-discussion] bug?

[<hu...@ya...>]

Hello, 

the docstring for compress in numpy give this

help(numpy.compress)

compress(condition, m, axis=None, out=None)
    compress(condition, x, axis=None) = those elements of x corresponding
    to those elements of condition that are "true".  condition must be the
    same size as the given dimension of x.


So (but perhaps I can misundertand the help due to my english) I don't 
undersand the following error, for me a and c array does have the same 
dimension and size. So someone can explain me the result please?

Thanks,

N.

In [86]: a = numpy.arange(9)

In [87]: a = numpy.arange(9).reshape(3,3)

In [88]: c = numpy.ones(9).reshape(3,3)

In [89]: numpy.compress(c,a)
---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent 
call last)

/home/gruel/tmp/Astro/FATBOY/<ipython console>

/home/gruel/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py in 
compress(condition, m, axis, out)
    353     except AttributeError:
    354         return _wrapit(m, 'compress', condition, axis, out)
--> 355     return compress(condition, axis, out)
    356
    357 def clip(m, m_min, m_max):

ValueError: condition must be 1-d array

Re: [Numpy-discussion] bug?

[Robert K. <rob...@gm...>]

hu...@ya... wrote:
> Hello, 
> 
> the docstring for compress in numpy give this
> 
> help(numpy.compress)
> 
> compress(condition, m, axis=None, out=None)
>     compress(condition, x, axis=None) = those elements of x corresponding
>     to those elements of condition that are "true".  condition must be the
>     same size as the given dimension of x.
> 
> 
> So (but perhaps I can misundertand the help due to my english) I don't 
> undersand the following error, for me a and c array does have the same 
> dimension and size. So someone can explain me the result please?

The docstring is a bit underspecified. The condition array *must* be a 1D array 
with the same size *as the given axis* of the other array (using the convention 
that axis=None implies operating over the flattened array).

There's simply no valid interpretation of this, for example:

   compress(array([[1, 0, 0],
                   [1, 1, 0]]), arange(6).reshape(2,3))

since numpy arrays cannot be "ragged".

-- 
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

Re: [Numpy-discussion] bug?

[Todd M. <jm...@st...>]

Hi Peter,

What you're demonstrating below looks like a bug in numarray which was
just recently solved:

https://sourceforge.net/tracker/index.php?func=detail&aid=784866&group_id=1369&atid=450446


As you've shown, numarray's astype() fails for some slices, notably
those which are offset from the base of the array and therefore have a
non-zero _byteoffset.   This is fixed in CVS now and will be "officially
released" soon.


On Mon, 2003-08-18 at 08:01, Peter Verveer wrote:
> Consider conversion of a slice using the astype() method:
> 
> >>> a = array([[1,2],[3,4]])
> >>> b = a[1, ...]
> >>> print b
> [3 4]
> 
> Conversion using the astype() method goes wrong:
> 
> >>> print b.astype(Float32)
> [ 1.  2.]
> 
> This fixes it:
> 
> >>> print b.copy().astype(Float32)
> [ 3.  4.]
> 
> A bug?
> 
> Cheers, Peter
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] Possible bug

[Colin J. W. <cj...@sy...>]

# ta.py to check Int8, Int16
import numarray as _n
import numarray.numerictypes as _nt
b= _n.arange(4, type= _nt.Int8)
print 'b, b._type:', b, b._type
c= b*1001                                        # Grief here - type not 
updated
print 'c, c._type:', c, c._type    
e= _n.array([1, -2, 3000, 4.6], type= _nt.Int8)  # undocumented feature 
fraction discarded
                                                 # and lowest eight bits 
retained as a signed
                                                 # integer.
print 'e, e._type:', e, e._type
f= _n.array([1, 2, 3, 4.6], type= _nt.Int8) * 9.6
print 'f, f._type:', f, f._type
g= (f.copy()*2000).astype(_nt.Int16)             # undocumented - see e 
above
print 'g, g._type:', g, g._type


--------------------------------------------------------------------
PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 
on win32.
Portions Copyright 1994-2001 Mark Hammond (mha...@sk...) - 
see 'Help/About PythonWin' for further copyright information.
 >>> b, b._type: [0 1 2 3] Int8
c, c._type: [  0 -23 -46 -69] Int8
e, e._type: [  1  -2 -72   4] Int8
f, f._type: [  9.6  19.2  28.8  38.4] Float64
g, g._type: [ 19200 -27136  -7937  11264] Int16

Colin W.

Re: [Numpy-discussion] Possible bug

[Todd M. <jm...@st...>]

These problems are (partially) addressed in numarray-0.7 with the
addition of a check_overflow parameter to numarray.fromlist().  The
checked fromlist is now used in the implementation of ufuncs (e.g.
multiply), preventing the silent truncation of scalar values to the type
of the array.  

Problem c:  solved -- 1001 scalar was silently truncated to Int8 before
multiplication.

Problem e:  solved -- 3000 was silently truncated to Int8 during
fromlist.  Use fromlist() rather than array() and add
check_overflow=1 parameter.

Problem f: rejected  -- working as designed, won't change.  Floating
point numbers passed into array() are silently truncated if the type is
not a floating point type.  Operating on an integer array and a floating
point scalar returns a floating point array by design;  likewise,
operating on an integer array with an integer scalar returns an integer
array.  This is all expected behavior.

Problem g: unaddressed -- working as designed, open to discussion.  The
silent truncation of g to Int16 is documented in the description of
astype().  It's possible to add a check_overflow flag to astype()

Thanks for the feedback,
Todd

On Mon, 2003-08-18 at 09:20, Colin J. Williams wrote:
> # ta.py to check Int8, Int16
> import numarray as _n
> import numarray.numerictypes as _nt
> b= _n.arange(4, type= _nt.Int8)
> print 'b, b._type:', b, b._type
> c= b*1001                                        # Grief here - type not 
> updated
> print 'c, c._type:', c, c._type    
> e= _n.array([1, -2, 3000, 4.6], type= _nt.Int8)  # undocumented feature 
> fraction discarded
>                                                  # and lowest eight bits 
> retained as a signed
>                                                  # integer.
> print 'e, e._type:', e, e._type
> f= _n.array([1, 2, 3, 4.6], type= _nt.Int8) * 9.6
> print 'f, f._type:', f, f._type
> g= (f.copy()*2000).astype(_nt.Int16)             # undocumented - see e 
> above
> print 'g, g._type:', g, g._type
> 
> 
> --------------------------------------------------------------------
> PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 
> on win32.
> Portions Copyright 1994-2001 Mark Hammond (mha...@sk...) - 
> see 'Help/About PythonWin' for further copyright information.
>  >>> b, b._type: [0 1 2 3] Int8
> c, c._type: [  0 -23 -46 -69] Int8
> e, e._type: [  1  -2 -72   4] Int8
> f, f._type: [  9.6  19.2  28.8  38.4] Float64
> g, g._type: [ 19200 -27136  -7937  11264] Int16
> 
> Colin W.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

Re: [Numpy-discussion] bug?

[Todd M. <jm...@st...>]

On Mon, 2003-08-18 at 08:31, Peter Verveer wrote:
> Hi Todd, 
> 
> Yes its the same bug, next time I will check the bug tracker before sounding 
> the alarm...
> 
> BTW what is the preferred way of submitting a bug? Through the sourceforge 
> page, or the mailing list?

It actually took me a few minutes to sort this question out.   The
tracker is definitely *easier* for me,  but that's not a good
discriminator.  More importantly,  if you use the tracker,  the bug
report won't get *lost*,  and thus the chances are improved that the
problem will actually get fixed.

For more serious stuff (like the astype() slicing bug),  it's good to
post to numpy-discussion-list also.  

Thanks again for the report,
Todd

-- 
Todd Miller <jm...@st...>