numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] comparing string array with None raises ValueError

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

On Thu, 2004-06-24 at 13:46, Sebastian Haase wrote:
> On Thursday 24 June 2004 10:31 am, Todd Miller wrote:
> > On Thu, 2004-06-24 at 13:06, Sebastian Haase wrote:
> > > Hi,
> > > I'm not sure if this is fixed already in CVS but here it goes:
> > > I'm working with record arrays, and trying to access a field with
> > >
> > > type '10a80' - that is, an array of 10 80 char 'strings' :
> > > >>> q.Mrc.hdr = q.Mrc.hdrArray[0].field
> > > >>> q.Mrc.hdr('title') != None
> >
> > Shouldn't this be:
> >
> > q.Mrc.hdr('title') != ""
> 
> (in my first reply, I forgot to point out that q.Mrc.hdr('title') is an ARRAY 
> of strings ! )
> 
> No, I understand that this makes more sense, but I have some "display 
> hook"-code that compares everything with None...
> In general it must be OK to compare anything with None, right ?
> (BTW, I get the same error with == and !=)

OK,  I see your point.  I talked it over with Perry and he made a
reasonable case for allowing comparisons with None (or any object). 
Perry argued that since None is a common default parameter value, it
might simplify code to not have to add logic to handle that case. 

If no one objects,  I'll change numarray.strings so that comparison of a
string array with any object not convertible to a string array results
in an array of False values.

Any objections?

Regards,
Todd

[Numpy-discussion] ObjectArray paramter order poll

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

A while back Colin Williams suggested that we change the parameter order
of numarray.objects.ObjectArray from:

def __init__(self, shape=None, objects=None, rank=None)

to:

def __init__(self, objects=None, shape=None, rank=None)

The new order emphasizes building object arrays from existing sequences,
while the old order emphasizes building empty (full of None) object
arrays of a specific shape.  Since array() and fromlist() already exist
to build from sequences,  I thought it was fine to keep the order as is,
plus I hate breaking s/w interfaces unless it was my idea. :-)

Opinions please?  

Regards,
Todd

Re: [Numpy-discussion] comparing string array with None raises ValueError

[Sebastian H. <ha...@ms...>]

On Thursday 24 June 2004 10:31 am, Todd Miller wrote:
> On Thu, 2004-06-24 at 13:06, Sebastian Haase wrote:
> > Hi,
> > I'm not sure if this is fixed already in CVS but here it goes:
> > I'm working with record arrays, and trying to access a field with
> >
> > type '10a80' - that is, an array of 10 80 char 'strings' :
> > >>> q.Mrc.hdr = q.Mrc.hdrArray[0].field
> > >>> q.Mrc.hdr('title') != None
>
> Shouldn't this be:
>
> q.Mrc.hdr('title') != ""

(in my first reply, I forgot to point out that q.Mrc.hdr('title') is an ARRAY 
of strings ! )

No, I understand that this makes more sense, but I have some "display 
hook"-code that compares everything with None...
In general it must be OK to compare anything with None, right ?
(BTW, I get the same error with == and !=)

Regards,
Sebastian Haase

Re: [Numpy-discussion] comparing string array with None raises ValueError

[Sebastian H. <ha...@ms...>]

On Thursday 24 June 2004 10:31 am, Todd Miller wrote:
> On Thu, 2004-06-24 at 13:06, Sebastian Haase wrote:
> > Hi,
> > I'm not sure if this is fixed already in CVS but here it goes:
> > I'm working with record arrays, and trying to access a field with
> >
> > type '10a80' - that is, an array of 10 80 char 'strings' :
> > >>> q.Mrc.hdr = q.Mrc.hdrArray[0].field
> > >>> q.Mrc.hdr('title') != None
>
> Shouldn't this be:
>
> q.Mrc.hdr('title') != ""

No, I understand that this makes more sense, but I have some "display 
hook"-code that compares everything with None...
In general it must be OK to compare anything with None, right ?
(BTW, I get the same error with == and !=)

Regards,
Sebastian Haase

Re: [Numpy-discussion] comparing string array with None raises ValueError

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

On Thu, 2004-06-24 at 13:06, Sebastian Haase wrote:
> Hi, 
> I'm not sure if this is fixed already in CVS but here it goes:
> I'm working with record arrays, and trying to access a field with 
> type '10a80' - that is, an array of 10 80 char 'strings' :
> >>> q.Mrc.hdr = q.Mrc.hdrArray[0].field
> >>> q.Mrc.hdr('title') != None

Shouldn't this be:

q.Mrc.hdr('title') != ""

Regards,
Todd

[Numpy-discussion] comparing string array with None raises ValueError

[Sebastian H. <ha...@ms...>]

Hi, 
I'm not sure if this is fixed already in CVS but here it goes:
I'm working with record arrays, and trying to access a field with 
type '10a80' - that is, an array of 10 80 char 'strings' :
>>> q.Mrc.hdr = q.Mrc.hdrArray[0].field
>>> q.Mrc.hdr('title') != None
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "/jws30/haase/PrLin/numarray/strings.py", line 431, in __ne__
    return self.StrCmp(other).__ne__(0)
  File "/jws30/haase/PrLin/numarray/strings.py", line 385, in StrCmp
    b = asarray(b0, kind=self.__class__)
  File "/jws30/haase/PrLin/numarray/strings.py", line 1024, in asarray
    return array(buffer, itemsize, shape, byteoffset, bytestride, kind)
  File "/jws30/haase/PrLin/numarray/strings.py", line 994, in array
    byteoffset=byteoffset, bytestride=bytestride)
  File "/jws30/haase/PrLin/numarray/strings.py", line 84, in __init__
    raise ValueError("Must define both shape & itemsize if buffer is None")
ValueError: Must define both shape & itemsize if buffer is None
>>> 
>>> print q.Mrc.hdr('title')
['tit1e seb says hi' '' '' '' '' '' '' '' '' '']
>>> 


Thanks for numarray ;-)

Sebastian Haase

Re: [Numpy-discussion] Compiling on windows?

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

On Thu, 2004-06-24 at 12:40, Tim Hochberg wrote:
>  I've been using numarray 0.8 since 0.9 has some bugs that I can't 
> easily work around. Since these have been fixed in CVS, I finally 
> decided to try to download and compile a copy of numarray from CVS. 
> Unfortunately, 'python setup.py build' bombs out almost imediately:
> 
> creating build\temp.win32-2.3
> creating build\temp.win32-2.3\Release
> creating build\temp.win32-2.3\Release\Src
> C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox 
> /MD /W3 /GX /DNDEBUG -IInclude/numarray -IC:\python23\include 
> -IC:\python23\PC /TcSrc\_convmodule.c 
> /Fobuild\temp.win32-2.3\Release\Src\_convmodule.obj_convmodule.c
> Src\_convmodule.c(683) : warning C4244: '=' : conversion from 'int ' to 
> 'float ', possible loss of data
> 
> ....
> 
> Src\_convmodule.c(2310) : error C2520: conversion from unsigned __int64 
> to double not implemented, use signed __int64
> error: command '"C:\Program Files\Microsoft Visual 
> Studio\VC98\BIN\cl.exe"' failed with exit status 2
> 
> 
> This on Windows XP, Python 2.3.2, VC++ 6.0. Any hints as to what I could 
> to make this work? 

Try:  

python setup.py install --gencode

Then try:

python setup.py build ...

if you must.  :-)

> I downloaded the source for version 0.9 and tried 
> compiling it but got the same set of errors.
> 
> Alternatively, is there going to be a 0.9.1 or 0.10 release soon?

numarray-1.0 should be out soon.


Regards,
Todd

[Numpy-discussion] Compiling on windows?

[Tim H. <tim...@co...>]

 I've been using numarray 0.8 since 0.9 has some bugs that I can't 
easily work around. Since these have been fixed in CVS, I finally 
decided to try to download and compile a copy of numarray from CVS. 
Unfortunately, 'python setup.py build' bombs out almost imediately:

creating build\temp.win32-2.3
creating build\temp.win32-2.3\Release
creating build\temp.win32-2.3\Release\Src
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox 
/MD /W3 /GX /DNDEBUG -IInclude/numarray -IC:\python23\include 
-IC:\python23\PC /TcSrc\_convmodule.c 
/Fobuild\temp.win32-2.3\Release\Src\_convmodule.obj_convmodule.c
Src\_convmodule.c(683) : warning C4244: '=' : conversion from 'int ' to 
'float ', possible loss of data

....

Src\_convmodule.c(2310) : error C2520: conversion from unsigned __int64 
to double not implemented, use signed __int64
error: command '"C:\Program Files\Microsoft Visual 
Studio\VC98\BIN\cl.exe"' failed with exit status 2


This on Windows XP, Python 2.3.2, VC++ 6.0. Any hints as to what I could 
to make this work? I downloaded the source for version 0.9 and tried 
compiling it but got the same set of errors.

Alternatively, is there going to be a 0.9.1 or 0.10 release soon?

Thanks,

-tim

Re: [Numpy-discussion] type of matrixmultiply result

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

On Thu, 2004-06-24 at 10:30, Rick White wrote:
> On 24 Jun 2004, Todd Miller wrote:
> 
> > On Thu, 2004-06-24 at 06:14, Curzio Basso wrote:
> >
> > > I noticed that when multiplying two matrices of type Float32, the result
> > > is Float64:
> >
> > I modified dot() and innerproduct() this morning to return Float32 and
> > Complex32 for like inputs.
> 
> I wonder whether it would be worth providing an option to accumulate
> the sums using Float64 and to convert to Float32 before storing them in
> an array.  I suspect that one reason this returned Float64 is that it
> is very easy to run into precision/roundoff problems in
> single-precision matrix multiplies.  You could avoid that by using
> doubles for the sum while still returning the result as a single.
> 				Rick

OK.  I implemented intermediate sums using Float64 and Complex64 but
single precision inputs will still result in single precision outputs.

Todd

RE: [Numpy-discussion] type of matrixmultiply result

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

On Thu, 2004-06-24 at 11:08, Perry Greenfield wrote:
> Rick White wrote:
> 
> > On 24 Jun 2004, Todd Miller wrote:
> > 
> > > On Thu, 2004-06-24 at 06:14, Curzio Basso wrote:
> > >
> > > > I noticed that when multiplying two matrices of type Float32, 
> > the result
> > > > is Float64:
> > >
> > > I modified dot() and innerproduct() this morning to return Float32 and
> > > Complex32 for like inputs.
> > 
> > I wonder whether it would be worth providing an option to accumulate
> > the sums using Float64 and to convert to Float32 before storing them in
> > an array.  I suspect that one reason this returned Float64 is that it
> > is very easy to run into precision/roundoff problems in
> > single-precision matrix multiplies.  You could avoid that by using
> > doubles for the sum while still returning the result as a single.
> > 				Rick
> > 
> I definitely agree. I'm pretty certain the reason it was done
> with double precision floats is the sensitivity to roundoff
> issues with matrix operations. I think Rick is right though that
> only intermediate calculations need to be done in double precision
> and that doesn't require the whole output array to be kept that way.
> 
> Perry 

OK.  I implemented intermediate sums using Float64 and Complex64 but
single precision inputs will still result in single precision outputs. 

Todd

RE: [Numpy-discussion] type of matrixmultiply result

[Perry G. <pe...@st...>]

Rick White wrote:

> On 24 Jun 2004, Todd Miller wrote:
> 
> > On Thu, 2004-06-24 at 06:14, Curzio Basso wrote:
> >
> > > I noticed that when multiplying two matrices of type Float32, 
> the result
> > > is Float64:
> >
> > I modified dot() and innerproduct() this morning to return Float32 and
> > Complex32 for like inputs.
> 
> I wonder whether it would be worth providing an option to accumulate
> the sums using Float64 and to convert to Float32 before storing them in
> an array.  I suspect that one reason this returned Float64 is that it
> is very easy to run into precision/roundoff problems in
> single-precision matrix multiplies.  You could avoid that by using
> doubles for the sum while still returning the result as a single.
> 				Rick
> 
I definitely agree. I'm pretty certain the reason it was done
with double precision floats is the sensitivity to roundoff
issues with matrix operations. I think Rick is right though that
only intermediate calculations need to be done in double precision
and that doesn't require the whole output array to be kept that way.

Perry 

Re: [Numpy-discussion] type of matrixmultiply result

[Rick W. <rl...@st...>]

On 24 Jun 2004, Todd Miller wrote:

> On Thu, 2004-06-24 at 06:14, Curzio Basso wrote:
>
> > I noticed that when multiplying two matrices of type Float32, the result
> > is Float64:
>
> I modified dot() and innerproduct() this morning to return Float32 and
> Complex32 for like inputs.

I wonder whether it would be worth providing an option to accumulate
the sums using Float64 and to convert to Float32 before storing them in
an array.  I suspect that one reason this returned Float64 is that it
is very easy to run into precision/roundoff problems in
single-precision matrix multiplies.  You could avoid that by using
doubles for the sum while still returning the result as a single.
				Rick

Re: [Numpy-discussion] type of matrixmultiply result

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

On Thu, 2004-06-24 at 06:14, Curzio Basso wrote:
> Hi.
> 
> I noticed that when multiplying two matrices of type Float32, the result 
> is Float64:
> 
> -----------------------------------------
> In [103]: a=NA.ones((2,2), NA.Float32)
> 
> In [104]: b=NA.ones((2,2), NA.Float32)
> 
> In [105]: c=NA.matrixmultiply(a,b)
> 
> In [106]: c.type()
> Out[106]: Float64
> -----------------------------------------
> 
> Since the matrix I'm going to multiply in practice are quite big, I'd 
> like to do the operation in Float32. Otherwise this is what I get:
> 
> Traceback (most recent call last):
>    File "/home/basso/work/python/port/apps/pca-heads.py", line 141, in ?
>      pc = NA.array(NA.matrixmultiply(cent, c), NA.Float32)
>    File "/home/basso/usr//lib/python/numarray/numarraycore.py", line 
> 1150, in dot    return ufunc.innerproduct(array1, _gen.swapaxes(array2, 
> -1, -2))
>    File "/home/basso/usr//lib/python/numarray/ufunc.py", line 2047, in 
> innerproduct
>      r = a.__class__(shape=adots+bdots, type=rtype)
> MemoryError
> 
> Any suggestion (apart from doing the operation one column at a time)?
> 

I modified dot() and innerproduct() this morning to return Float32 and
Complex32 for like inputs.  This is in CVS now.  numarray-1.0 is
dragging out,  but will nevertheless be released relatively soon.

I'm curious about what your array dimensions are.  When I implemented
matrixmuliply for numarray,  I was operating under the assumption that
no one would be multiplying truly huge arrays because it's an O(N^3)
algorithm.

Regards,
Todd

> thanks
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] compress function

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

The documentation of the compress function states that the condition 
must be equal to the given axis of the array that is compressed. e.g.:

 >>> a = array([[1,2],[3,4]])
 >>> print compress([1,0], a, axis = 1)
[[1]
  [3]]

However, this also works fine:

 >>> print compress([[1,0],[0,1]], a)
[1, 4]

which is great (I need that) but not documented. Is that behaviour 
intended? If so it maybe should be documented.

Cheers, Peter

[Numpy-discussion] =?ISO-8859-1?Q?Re:_median_filtering_question_--_masked_arrays_?= =?ISO-8859-1?Q?=A0?=

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

> Does anyone have a hint for applying a median filter to a masked 2D
> array in numarray?
>
> I"ve been using the kludge of extracting a normal array with the
> masked data replaced by the overall median of the array and median
> filtering that (with the appropriate nd_image method). But this is a
> crude approximation and I"d like to do better -- preferably without
> coding my own median filter in C.

Masks are not supported by the filters in nd_image. It could be done, 
but that would be a considerable effort for a rather exotic feature, so 
that won't happen soon. In the near future I will however add support 
for generic filters where you can provide your own filter function to 
be executed at each point. That may make it easy enough to roll your 
own function.

Cheers, Peter

[Numpy-discussion] type of matrixmultiply result

[Curzio B. <cur...@un...>]

Hi.

I noticed that when multiplying two matrices of type Float32, the result 
is Float64:

-----------------------------------------
In [103]: a=NA.ones((2,2), NA.Float32)

In [104]: b=NA.ones((2,2), NA.Float32)

In [105]: c=NA.matrixmultiply(a,b)

In [106]: c.type()
Out[106]: Float64
-----------------------------------------

Since the matrix I'm going to multiply in practice are quite big, I'd 
like to do the operation in Float32. Otherwise this is what I get:

Traceback (most recent call last):
   File "/home/basso/work/python/port/apps/pca-heads.py", line 141, in ?
     pc = NA.array(NA.matrixmultiply(cent, c), NA.Float32)
   File "/home/basso/usr//lib/python/numarray/numarraycore.py", line 
1150, in dot    return ufunc.innerproduct(array1, _gen.swapaxes(array2, 
-1, -2))
   File "/home/basso/usr//lib/python/numarray/ufunc.py", line 2047, in 
innerproduct
     r = a.__class__(shape=adots+bdots, type=rtype)
MemoryError

Any suggestion (apart from doing the operation one column at a time)?

thanks

[Numpy-discussion] THE CHEAPEST EVER SOFTWARES U SEE & WE SHIIP WORLDWIDE makes somebody

[Georgene M. <buu...@sh...>]

making fellow stay fixed advantage neck secret pocket money believe 
important gotten learn nickel handwriting house 

[Numpy-discussion] numarray.sum should raise exception for wrong axis argument - and slicing ...

[Sebastian H. <ha...@ms...>]

Hi,
please take a look at this:
>>> na.sum( na.zeros((2,6)) )
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , 0)
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , 1)
[0 0]
>>> na.sum( na.zeros((2,6)) , 2)
[0 0]
>>> na.sum( na.zeros((2,6)) , 3)
[0 0]
>>> na.sum( na.zeros((2,6)) , 4)
[0 0]
>>> na.sum( na.zeros((2,6)) , -1)
[0 0]
>>> na.sum( na.zeros((2,6)) , -2)
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , -3)
[0 0]
>>> na.sum( na.zeros((2,6)) , -4)
[0 0]
>>> 

I think here should be a ValueError exception thrown rather than defaulting to 
the '-1'-axis.  Comments ?

Also this applies to (all?) other functions that have an 'axis' argument.
And further I just found that putting "too many slicings" to an array also 
gets silently ignored:
>>> b.shape
(7, 128, 128, 128)
>>> b[2,2,2,2,3]
Traceback (most recent call last):
  File "<input>", line 1, in ?
IndexError: too many indices.

BUT:
>>> b[2:3 , 2:3 , 2:3 , 2:3 , 2:3 , 2:3]
[[[[ 0.]]]]


I find this very confusing !! Is there any good reason not to have the 
"IndexError" exception in all cases ?

Thanks,
Sebastian Haase

[Numpy-discussion] printing character array object

[Faheem M. <fa...@em...>]

Hi, it's me again. This time I am having problems with printing out a
character array object (attached in cPickle format). I don't understand
what the error message means.

If you load the

>>> import cPickle
>>> cPickle.dump(foo,open('foo.save','w'))
>>> foo
[tons of error messages terminating in]
libnumarray.error: copy1bytes: access beyond buffer. offset=6 buffersize=6

Looks like the problem is with numarray. The character array is 100x20 and
I can't see any intrinsic problem with printing it out.

>>> foo.getshape()
Out[73]: (100, 20)

Thanks for any clarification.

                                                              Faheem.

Re: [Numpy-discussion] Java version for numarray?

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

On Mon, 2004-06-07 at 07:11, Francesc Alted wrote:
> Hi,
> 
> I'm using numarray objects basically like data containers for fast I/O
> purposes in the context of pytables. I'm thinking now to port part of my
> code to Java, and I'd like to use Jython to easy the transition. I've seen
> that a there is a port of Numeric to Jython
> (http://jnumerical.sourceforge.net/), and I thought that I could use these
> Numeric objects as containers. Unfortunately, there are a couple of objects
> that pytables relies on, namely RecArray and CharArray, that are not
> supported by Numeric.
> 
> My questions are:
> 
> - I think that both RecArray and CharArray modules are written in pure
> python, so the porting to Jython should be relatively easy, provided I'm
> successful making them to use Numeric objects instead of NumArray objects.
> What do you think?

Sounds hard.  I doubt there is enough commonality with the numarray to
make bolting on the pure-Python RecArray and CharArray implementations
reasonable.  RecArray and CharArray are very much dependent on
generic.NDArray;  I doubt they're easy to port to Numeric.

>  Would that be feasible?

I don't think so.

> - Is there any effort going on in order to have an implementation of
> numarray ready for use in Jython?

No.

Sorry about the slow response,
Todd

Re: [Numpy-discussion] convolve2d

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

On Tue, 2004-06-22 at 11:51, Michel Sanner wrote:
> Hello,
> 
> I started using numarray for doing 2D convolutions on images.  I noticed 
> that
> 
> import numarray.examples.convolve.high_level as convolve
> convolve.Convolve2d(kernel, in, out)
> 

Here's another (quick?) test which might help localize the problem.  Do:

convolve.Convolve2d(kernel, in, out, fft=1)

The underlying Convolve2d implementations are very different depending
on the use of FFT.

Regards,
Todd

Re: [Numpy-discussion] convolve2d

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

On Tue, 2004-06-22 at 11:51, Michel Sanner wrote:
> Hello,
> 
> I started using numarray for doing 2D convolutions on images.  I noticed 
> that
> 
> import numarray.examples.convolve.high_level as convolve
> convolve.Convolve2d(kernel, in, out)
> 
> only works on square images.  For images that are not square I get lots 
> of noise in the background.

I looked at the code and couldn't find any row/column typos.  In theory,
Convolve2d works for non-square arrays.

What do kernel.info() and data.info() say?

> Also I was wondering is using the high_level API is most efficient?  

For CPU, my guess is yes.  The point access macros and functions are
definitely slower than the high level API in any scenario where you're
not running out of memory.  The 1D API improves space usage but is less
efficient in time.  The Numeric compatible API is layered over the high
level API.

> Currently my image is a Numeric
> array (grabbed from the OpenGL frame buffer) which I convert to a 
> numarray to do the convolution and back to a Numeric array.  

It's also possible something is happening during this conversion.  It'd
be good to round-trip the Numeric array and make sure the end product
looks like the original.

> In the future I hope to completely replace Numeric by numarray.

Great!

Regards,
Todd

[Numpy-discussion] median filtering question -- masked arrays

[Russell E O. <rowen@u.washington.edu>]

Does anyone have a hint for applying a median filter to a masked 2D 
array in numarray?

I've been using the kludge of extracting a normal array with the 
masked data replaced by the overall median of the array and median 
filtering that (with the appropriate nd_image method). But this is a 
crude approximation and I'd like to do better -- preferably without 
coding my own median filter in C.

-- Russell

[Numpy-discussion] convolve2d

[Michel S. <sa...@sc...>]

Hello,

I started using numarray for doing 2D convolutions on images.  I noticed 
that

import numarray.examples.convolve.high_level as convolve
convolve.Convolve2d(kernel, in, out)

only works on square images.  For images that are not square I get lots 
of noise in the background.

Also I was wondering is using the high_level API is most efficient?  
Currently my image is a Numeric
array (grabbed from the OpenGL frame buffer) which I convert to a 
numarray to do the convolution
and back to a Numeric array.  In the future I hope to completely replace 
Numeric by numarray.

Thanks for any input

-Michel

-- 

-----------------------------------------------------------------------
   o
  /    Michel F. Sanner Ph.D.            The Scripps Research Institute
o      Associate Professor               Department of Molecular Biology
  \                                      10550 North Torrey Pines Road
   o   Tel. (858) 784-2341               La Jolla, CA 92037
  /    Fax. (858) 784-2860
o     sa...@sc...                 http://www.scripps.edu/~sanner
-----------------------------------------------------------------------

Re: [Numpy-discussion] numarray.concatenate for character arrays

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

Hi Faheem,

This is a bug.  It'll be fixed in numarray-1.0 which should hopefully be
released this week.

Regards,
Todd

On Mon, 2004-06-21 at 20:17, Faheem Mitha wrote:
> Dear People,
> 
> Is the function numarray.concatenate supposed to work for character
> arrays? It doesn't for me. Do I need to write my own? Thanks in
> advance. Please cc me, I'm not subscribed.
> 
>                                                            Faheem.
> 
> In [17]: foo
> Out[17]:
> CharArray([['T', 'T'],
>            ['C', 'A']])
> 
> In [18]: bar
> Out[18]:
> CharArray([['G', 'G'],
>            ['G', 'G']])
> 
> In [23]: numarray.concatenate((foo,bar))
> ---------------------------------------------------------------------------
> error                                     Traceback (most recent call
> last)
> 
> /home/faheem/wc/corrmodel/trunk/<console>
> 
> /usr/lib/python2.3/site-packages/numarray/generic.py in
> concatenate(arrs, axis)
>    1018     arrs = map(_nc.asarray, arrs)
>    1019     if axis == 0:
> -> 1020         return _concat(arrs)
>    1021     else:
>    1022         return swapaxes(_concat([swapaxes(m,axis,0) for m in
>    arrs]), axis, 0)
> 
> /usr/lib/python2.3/site-packages/numarray/generic.py in _concat(arrs)
>    1000         convType = ufunc._maxPopType(arrs)
>    1001     except TypeError:
> -> 1002         dest = arrs[0]._clone(shape=destShape)
>    1003     else:
>    1004         dest  = arrs[0].__class__(shape=destShape,
>    type=convType)
> 
> /usr/lib/python2.3/site-packages/numarray/generic.py in _clone(self,
> shape)
>     783     def _clone(self, shape):
>     784         c = self.copy()
> --> 785         c.resize(shape)
>     786         return c
>     787
> 
> /usr/lib/python2.3/site-packages/numarray/generic.py in resize(self,
> shape, *args)
>     854                     self[offset:offset+olen] = self[0:olen]
>     855                     offset += olen
> --> 856                 self[offset:nlen] = self[0:nlen-offset]
>     857         else:   # zero fill resized zero-length numarray
>     858             self[:] = 0
> 
> /usr/lib/python2.3/site-packages/numarray/strings.py in
> _copyFrom(self, arr)
>     217         me = self._byteView()
>     218         if self._itemsize <= arr._itemsize:
> --> 219             me[:] = it[..., :self._itemsize]
>     220         else:
>     221             me[...,:it._shape[-1]] = it
> 
> error: copy1bytes: access beyond buffer. offset=8 buffersize=8
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>