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

[Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Lars B. <lar...@go...>]

Hi all,

recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
9.1. At first everything was fine, but the scipy test produced a few errors. 
The reason was a little difference:

numpy svn(1.0.dev3233) with Intel C compiler (Python 2.5):
-----------------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:x[i]
Out[4]:1.0

numpy svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
--------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:print x[i]
Out[4]:array([1])

The Intel version gives me a scalar whereas the gcc version an array. Maybe 
Python 2.5 is causing this problem but my first guess was the compiler. 

A typical error message from scipy.test(10):
======================================================================
ERROR: check_chebyc (scipy.special.tests.test_basic.test_chebyc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "[...]/lib/python2.5/site-packages/scipy/special/tests/test_basic.py", 
line 667, in check_chebyc
    C1 = chebyc(1)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
461, in chebyc
    p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: 
1.0/sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
78, in __init__
    equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
TypeError: object of type 'numpy.complex128' has no len()

Does anyone know how to resolve the problem?

Best regards,

Lars

[Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Lars B. <lar...@go...>]

Hi all,

recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
9.1. At first everything was fine, but the scipy test produced a few errors. 
The reason was a little difference:

numpy svn(1.0.dev3233) with Intel C compiler (Python 2.5):
-----------------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:x[i]
Out[4]:1.0

numpy svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
--------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:print x[i]
Out[4]:array([1])

The Intel version gives me a scalar whereas the gcc version an array. Maybe 
Python 2.5 is causing this problem but my first guess was the compiler. 

A typical error message from scipy.test(10):
======================================================================
ERROR: check_chebyc (scipy.special.tests.test_basic.test_chebyc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "[...]/lib/python2.5/site-packages/scipy/special/tests/test_basic.py", 
line 667, in check_chebyc
    C1 = chebyc(1)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
461, in chebyc
    p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: 
1.0/sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
78, in __init__
    equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
TypeError: object of type 'numpy.complex128' has no len()

Does anyone know how to resolve the problem?

Best regards,

Lars

Re: [Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Travis O. <oli...@ee...>]

Lars Bittrich wrote:

>Hi all,
>
>recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
>9.1. At first everything was fine, but the scipy test produced a few errors. 
>The reason was a little difference:
>
>numpy svn(1.0.dev3233) with Intel C compiler (Python 2.5):
>-----------------------------------------------------------
>In [1]:from numpy import ones, zeros, integer
>
>In [2]:
>
>In [2]:x = ones(1)
>
>In [3]:i = zeros(1, integer)
>
>In [4]:x[i]
>Out[4]:1.0
>
>numpy svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
>--------------------------------------------------
>In [1]:from numpy import ones, zeros, integer
>
>In [2]:
>
>In [2]:x = ones(1)
>
>In [3]:i = zeros(1, integer)
>
>In [4]:print x[i]
>Out[4]:array([1])
>
>The Intel version gives me a scalar whereas the gcc version an array. Maybe 
>Python 2.5 is causing this problem but my first guess was the compiler. 
>
>  
>

This is a Python 2.5 issue (the new __index__ method) was incorrectly 
implemented and allowing a 1-d array to be interpreted as an index.

This should be fixed in SVN.

-Travis

[Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Lars B. <lar...@go...>]

Hi all,

recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
9.1. At first everything was fine, but the scipy test produced a few errors. 
The reason was a little difference:

numpy svn(1.0.dev3233) with Intel C compiler (Python 2.5):
-----------------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:x[i]
Out[4]:1.0

numpy svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
--------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:print x[i]
Out[4]:array([1])

The Intel version gives me a scalar whereas the gcc version an array. Maybe 
Python 2.5 is causing this problem but my first guess was the compiler. 

A typical error message from scipy.test(10):
======================================================================
ERROR: check_chebyc (scipy.special.tests.test_basic.test_chebyc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "[...]/lib/python2.5/site-packages/scipy/special/tests/test_basic.py", 
line 667, in check_chebyc
    C1 = chebyc(1)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
461, in chebyc
    p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: 
1.0/sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
78, in __init__
    equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
TypeError: object of type 'numpy.complex128' has no len()

Does anyone know how to resolve the problem?

Best regards,

Lars

Re: [Numpy-discussion] numarray and/or Numeric with python 2.5?

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

Russell E. Owen wrote:
> Has anyone tried to build numarray or Numeric with python 2.5? Since the
>   
numarray builds and runs fine for Python-2.5,  but only as 32-bit.   
> type of array index was changed, I'm wondering if it works (and if so, 
>   
NOTE: numarray does not exploit the new ssize_t index in Python-2.5 so 
numarray is not 64-bit enabled.

Regards,
Todd

[Numpy-discussion] numarray and/or Numeric with python 2.5?

[Russell E. O. <ro...@ce...>]

Has anyone tried to build numarray or Numeric with python 2.5? Since the 
type of array index was changed, I'm wondering if it works (and if so, 
if there are any gotchas to worry about).

(And yes, I do plan to switch to numpy, but meanwhile I'm still using 
numarray and Numeric.)

Regards,

-- Russell

Re: [Numpy-discussion] Hi

[Jeno K. <per...@in...>]

Hi,

ClAxLIS

VlAxGRA

AMBxlEN

VALxlUM

Economize over 50% http://www.defunjeriondsafun.com
=20
  _____ =20


farms. The only really puzzling thing about the 3D map was what looked
enthusiastically. My medication was beginning to override the pain and
that I could see-except in the close vicinity of the device. I moved

[Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Lars B. <lar...@go...>]

Hi all,

recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
9.1. At first everything was fine, but the scipy test produced a few errors. 
The reason was a little difference:

latest svn(1.0.dev3233) with Intel C compiler (Python 2.5):
-----------------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:x[i]
Out[4]:1.0

latest svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
--------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:print x[i]
Out[4]:array([1])

The Intel version gives me a scalar whereas the gcc version an array. Maybe 
Python 2.5 is causing this problem but my first guess was the compiler. 

A typical error message from scipy.test(10):
======================================================================
ERROR: check_chebyc (scipy.special.tests.test_basic.test_chebyc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "[...]/lib/python2.5/site-packages/scipy/special/tests/test_basic.py", 
line 667, in check_chebyc
    C1 = chebyc(1)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
461, in chebyc
    p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: 
1.0/sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
78, in __init__
    equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
TypeError: object of type 'numpy.complex128' has no len()

Does anyone know how to resolve the problem?

Best regards,

Lars

[Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

[Lars B. <lar...@go...>]

Hi all,

recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler 
9.1. At first everything was fine, but the scipy test produced a few errors. 
The reason was a little difference:

latest svn(1.0.dev3233) with Intel C compiler (Python 2.5):
-----------------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:x[i]
Out[4]:1.0

latest svn(1.0.dev3233) with GCC 3.3 (Python 2.3):
--------------------------------------------------
In [1]:from numpy import ones, zeros, integer

In [2]:

In [2]:x = ones(1)

In [3]:i = zeros(1, integer)

In [4]:print x[i]
Out[4]:array([1])

The Intel version gives me a scalar whereas the gcc version an array. Maybe 
Python 2.5 is causing this problem but my first guess was the compiler. 

A typical error message from scipy.test(10):
======================================================================
ERROR: check_chebyc (scipy.special.tests.test_basic.test_chebyc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "[...]/lib/python2.5/site-packages/scipy/special/tests/test_basic.py", 
line 667, in check_chebyc
    C1 = chebyc(1)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
461, in chebyc
    p = orthopoly1d(x,w,hn,kn,wfunc=lambda x: 
1.0/sqrt(1-x*x/4.0),limits=(-2,2),monic=monic)
  File "[...]/lib/python2.5/site-packages/scipy/special/orthogonal.py", line 
78, in __init__
    equiv_weights = [weights[k] / wfunc(roots[k]) for k in range(len(roots))]
TypeError: object of type 'numpy.complex128' has no len()

Does anyone know how to resolve the problem?

Best regards,

Lars

[Numpy-discussion] bincount on multidimensional array (missing 'axis' parameter)

[Emanuele O. <oli...@it...>]

Hi,
I have to perform bincount on each column of a matrix so I was wondering
why there is no 'axis=?' parameter in bincount function. Currently I'm
looping through columns using a python loop but I'd appreciate to have
the loop embedded in the bincount function (and possibily using a C loop,
since I'm doing this stuff thousands times in a case of many columns).

Is there a good alternative solution to extending bincount? Suggestions?

Thanks in advance,

Emanuele

Re: [Numpy-discussion] Problem building from svn under cygwin

[Kyle F. <kf...@co...>]

You're correct.  I built python with cygwin.  Thanks for the clue.


Robert Kern wrote:

Coatimundi wrote:
 > I have the latest cygwin environment and am using gcc 3.4.4. to build numpy.
 > 
 > Configure works:
 > 
 >     python setup.py configure --compiler=mingw32
 > 
 > Build fails:
 > 
 >     python setup.py build --compiler=mingw32
 
 What Python are you using? It looks like you built Python 2.5 using cygwin (that 
 is, the UNIX emulation layer). You cannot build your extensions with mingw32 in 
 that case. Don't use --compiler at all and you will be fine.
 
 If you are using the regular Python binaries, then you should be using 
 --compiler=mingw32, but you're getting the wrong Python headers in that case.
 
 -- 
 Robert Kern

[Numpy-discussion] Adding an assert to ctypeslib.py

[Gael V. <gae...@no...>]

    Hi,

I just lost a bit of time because I had an old version of ctypes (the
one that comes with ubuntu dapper). It doesn't work with ctypeslib.py. I
think we should add a warning just after the import.

Cheers,

Ga=EBl

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

[Francesc A. <fa...@ca...>]

El dv 29 de 09 del 2006 a les 16:27 -0600, en/na Travis Oliphant va
escriure:
> Francesc Altet wrote:
>=20
> >I see. Thanks for the explanation.
> > =20
> >
> You deserve the thanks for the great testing of less-traveled corners of=20
> NumPy.   It's exactly the kind of thing needed to get NumPy ready for=20
> release.=20

You are welcome, but actually the merit is more of the pytables test
suite than mine :-)

Travis, I've expressed publicly many times my gratitude to you, but I'm
going to do so once more(so, be ready :-): I was absolutely thrilled
that each and everyone of my bug reports were either solved or declared
features in a matter of 1 or 2 days as maximum, and this is just
*amazing* in a complex software like NumPy. I don't need to say it again
(but will do): You have made of NumPy *the* reference of python array
packages, and better that this, you have made this only in one year and
a half! Definitely, I have come to the conclusion that you are not
human, but rather a MONSTER! :-)

Also thanks goes to Charles Harris, for implementing very fine-tuned
sorting algorithms in both numpy and numarray packages. His work is very
useful for us.

Finally, and although not directly related with numpy, I'd like to
express my gratitude and acknowledgement to David Cooke (and Tim
Hochberg) for it's work on numexpr: it's a perfect complement to numpy
in that it allows to accelerate even more many of the basic operations
with arrays.

All of you, and the rest of the numpy community are a first-class team,
and this is why it makes me so happy to help you!

--=20
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   C=C3=A1rabos Coop. V.   Enjoy Data
 "-"

Re: [Numpy-discussion] Problem building from svn under cygwin

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

Coatimundi wrote:
> I have the latest cygwin environment and am using gcc 3.4.4. to build numpy.
> 
> Configure works:
> 
>     python setup.py configure --compiler=mingw32
> 
> Build fails:
> 
>     python setup.py build --compiler=mingw32

What Python are you using? It looks like you built Python 2.5 using cygwin (that 
is, the UNIX emulation layer). You cannot build your extensions with mingw32 in 
that case. Don't use --compiler at all and you will be fine.

If you are using the regular Python binaries, then you should be using 
--compiler=mingw32, but you're getting the wrong Python headers in that case.

-- 
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] Problem building from svn under cygwin

[Coatimundi <coa...@co...>]

I have the latest cygwin environment and am using gcc 3.4.4. to build numpy.

Configure works:

    python setup.py configure --compiler=mingw32

Build fails:

    python setup.py build --compiler=mingw32

While building numpy.random.mtrand I get this:

    _configtest.c:7:2: #error No _WIN32


and a little bit later the build aborts completely on multiarray with this:

building 'numpy.core.multiarray' extension
compiling C sources
C compiler: gcc -mno-cygwin -mdll -O -Wall

creating build/temp.cygwin-1.5.21-i686-2.5
creating build/temp.cygwin-1.5.21-i686-2.5/numpy
creating build/temp.cygwin-1.5.21-i686-2.5/numpy/core
creating build/temp.cygwin-1.5.21-i686-2.5/numpy/core/src
compile options: '-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core/src 
-Inumpy/core/include -Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core 
-Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.5 -c'
gcc -mno-cygwin -mdll -O -Wall 
-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core/src -Inumpy/core/include 
-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core -Inumpy/core/src 
-Inumpy/core/include -I/usr/local/include/python2.5 -c 
numpy/core/src/multiarraymodule.c -o 
build/temp.cygwin-1.5.21-i686-2.5/numpy/core/src/multiarraymodule.o
In file included from /usr/local/include/python2.5/Python.h:57,
                 from numpy/core/src/multiarraymodule.c:18:
/usr/local/include/python2.5/pyport.h:226:24: sys/select.h: No such file 
or directory
In file included from /usr/local/include/python2.5/Python.h:57,
                 from numpy/core/src/multiarraymodule.c:18:
/usr/local/include/python2.5/pyport.h:226:24: sys/select.h: No such file 
or directory

I am puzzled, because /usr/include/sys/select.h actually does exist on 
my cygwin installation.  But maybe that's not what pyport.h is actually 
looking for???

I've been banging away at this for several hours, so I must be doing 
something silly.  Any help will be much appreciated. 

Thanks!

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

[Travis O. <oli...@ee...>]

Francesc Altet wrote:

>I see. Thanks for the explanation.
>  
>
You deserve the thanks for the great testing of less-traveled corners of 
NumPy.   It's exactly the kind of thing needed to get NumPy ready for 
release. 

-Travis

[Numpy-discussion] Q: NumPy (svn) with cygwin build error?

[Kyle F. <coa...@ho...>]

Hello.

Starting from a freshly installed cygwin, I have built Python 2.5, ATLAS and 
LAPACK all from source using gcc 3.4.4 (cygming special) for both the C and 
f77 compilers.

Now I am trying to build NumPy from SVN.  I have edited site.cfg so that

  python setup.py  config --compiler=mingw32

finds all of the linear algebra packs and completes without error.  Then I 
fire off

  python setup.py  build --compiler=mingw32

and I soon get (while building extension numpy.random.mtrand)

  _configtest.c:7:2: #error No _WIN32

which is not immediately fatal but definitely a concern.  Soon after, 
building numpy.core.multiarray gives me this:

building 'numpy.core.multiarray' extension
compiling C sources
C compiler: gcc -mno-cygwin -mdll -O -Wall

creating build/temp.cygwin-1.5.21-i686-2.5
creating build/temp.cygwin-1.5.21-i686-2.5/numpy
creating build/temp.cygwin-1.5.21-i686-2.5/numpy/core
creating build/temp.cygwin-1.5.21-i686-2.5/numpy/core/src
compile options: '-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core/src 
-Inumpy/core/include -Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core 
-Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.5 -c'
gcc -mno-cygwin -mdll -O -Wall 
-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core/src -Inumpy/core/include 
-Ibuild/src.cygwin-1.5.21-i686-2.5/numpy/core -Inumpy/core/src 
-Inumpy/core/include -I/usr/local/include/python2.5 -c 
numpy/core/src/multiarraymodule.c -o 
build/temp.cygwin-1.5.21-i686-2.5/numpy/core/src/multiarraymodule.o
In file included from /usr/local/include/python2.5/Python.h:57,
                 from numpy/core/src/multiarraymodule.c:18:
/usr/local/include/python2.5/pyport.h:226:24: sys/select.h: No such file or 
directory
In file included from /usr/local/include/python2.5/Python.h:57,
                 from numpy/core/src/multiarraymodule.c:18:
/usr/local/include/python2.5/pyport.h:226:24: sys/select.h: No such file or 
directory

I am puzzzled, because /usr/include/sys/select.h does exist.  But maybe 
that's not what pyport.h is actually looking for?

I've been banging away at this for several hours, so I must be doing 
something silly.  Any help will be much appreciated.

Thanks!

_________________________________________________________________
Express yourself - download free Windows Live Messenger themes! 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/themes/vibe/default.aspx?locale=en-us&source=hmtagline

Re: [Numpy-discussion] Incorrect removal of NULL char in buffers

[Travis O. <oli...@ie...>]

Francesc Altet wrote:
> Hi,
>
>
> However, for string values, numpy seems to work in a strange way. 
> The numarray have an expected behaviour, IMO:
>
> In [100]: numarray.strings.array(buffer="a\x00b"*4, itemsize=4, shape=3)
> Out[100]: CharArray(['a', '', 'ba'])  
>
>   
I'm not sure why you think this is "expected."   You have 
non-terminating NULLs in this array and yet they are not printing for you.

Just look at the tostring()...

> but numpy  haven't:
>
> In [101]: numpy.ndarray(buffer="a\x00b"*4, dtype="S4", shape=3)
> Out[101]:
> array([aba, ba, bab],
>       dtype='|S4')
>
> i.e. it seems like numpy is striping-off NULL chars before building the object 
> and I don't think this is correct.
>   

Hmmm.  I don't see that at all.  This is what I get (version of numpy is 
1.0.dev3233)

In [33]: numpy.ndarray(buffer="a\x00b"*4, dtype="S4", shape=3)
Out[33]:
array(['a\x00ba', '\x00ba', 'ba\x00b'],
      dtype='|S4')

which to me is very much expected.   I.e. only terminating NULLs are 
stripped off of the strings on printing.   I think you are getting 
different results because string printing used to not include the quotes 
(which had the side-effect of not printing NULLs in the middle of 
strings).  They are still there, just not showing up in your output.

In the end both numarray and numpy have the same data stored 
internally.  It's just a matter of how it is being printed that seems to 
differ a bit.  From my perspective, only NULLs at the end of strings 
should be stripped off and that is the (current) behavior of NumPy.

You are getting different results, because the array-printing for 
strings was recently updated (to insert the quotes so that it makes more 
sense).    Without these changes, I think the NULLs were being stripped 
away on printing.  In other words, something like

print 'a\x00ba'

aba

used to be happening. 

-Travis

Re: [Numpy-discussion] Negative values with unsigned data types problems

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

Francesc Altet wrote:
> Hi,
> 
> I'm writing this here because the numpy Trac seems down:
> 
> {{{
> Oops...
> 
> Trac detected an internal error: The Trac Environment needs to be upgraded. 
> Run trac-admin /home/scipy/trac/numpy upgrade"
> }}}

It's back up.

-- 
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] Non-writeable default for numpy.ndarray

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

Travis Oliphant wrote:
> Tim Hochberg wrote:
>   
>> Francesc Altet wrote:
>>   
>> It's not that the it's being built from ndarray, it's that the buffer 
>> that you are passing it is read only. 
>>     
> This is correct.
>   
>> In fact, I'd argue that allowing 
>> the writeable flag to be set to True in this case is actually a bug. 
>>   
>>     
> It's actually intentional.  Strings used as buffers are allowed to be 
> writeable.  This is an explicit design decision to allow pickles to load 
> without making 2 copies of the memory.   The pickled string that Python 
> creates is used as the actual memory for loaded arrays.
>
> Now, I suppose it would be possible to still allow this but be more 
> finnicky about when a string-used-as-the-memory can be set writeable 
> (i.e. we are the only reference to it).  But, this would be a fragile 
> solution as well. 
>
> My inclination is to just warn users not to use strings as buffers 
> unless they know what they are doing.  The fact that it is read-only by 
> default is enough of a guard against "accidentally" altering a string 
> you didn't want to alter.
>   
That makes sense.

Someday, when string/unicode => bytes/string, we'll be able to use the 
bytes type for this and it'll be much cleaner. But not for a while I 
imagine.

-tim

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

[Travis O. <oli...@ie...>]

Tim Hochberg wrote:
> Francesc Altet wrote:
>   
> It's not that the it's being built from ndarray, it's that the buffer 
> that you are passing it is read only. 
This is correct.
> In fact, I'd argue that allowing 
> the writeable flag to be set to True in this case is actually a bug. 
>   
It's actually intentional.  Strings used as buffers are allowed to be 
writeable.  This is an explicit design decision to allow pickles to load 
without making 2 copies of the memory.   The pickled string that Python 
creates is used as the actual memory for loaded arrays.

Now, I suppose it would be possible to still allow this but be more 
finnicky about when a string-used-as-the-memory can be set writeable 
(i.e. we are the only reference to it).  But, this would be a fragile 
solution as well. 

My inclination is to just warn users not to use strings as buffers 
unless they know what they are doing.  The fact that it is read-only by 
default is enough of a guard against "accidentally" altering a string 
you didn't want to alter.

-Travis

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

[Francesc A. <fa...@ca...>]

A Divendres 29 Setembre 2006 18:12, Tim Hochberg va escriure:
> It's not that the it's being built from ndarray, it's that the buffer
> that you are passing it is read only. In fact, I'd argue that allowing
> the writeable flag to be set to True in this case is actually a bug.
>
> Consider this slightly modified example:
>      >>> a =3D "12345"*4
>      >>> f4=3Dnumpy.ndarray(buffer=3Da, dtype=3D"f4", shape=3D3)
>      >>> f4[2] =3D 99
>
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     RuntimeError: array is not writeable
>
>      >>> f4.flags.writeable =3D True
>      >>> a
>
>     '12345123451234512345'
>
>      >>> f4.flags.writeable =3D True
>      >>> f4[2] =3D 99
>      >>> a
>
>     '12345123\x00\x00\xc6B34512345'
>
> The original, *immutable* string has been mutated. This could get you
> into real trouble in certain situations.

I see. Thanks for the explanation.

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

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

Francesc Altet wrote:
> Hello,
>
> Is the next a bug a feature?
>
> In [102]: f4=numpy.ndarray(buffer="a\x00b"*4, dtype="f4", shape=3)
>
> In [103]: f4
> Out[103]: array([  2.60561966e+20,   8.94319890e-39,   5.92050103e+20], 
> dtype=float32)
>
> In [104]: f4[2] = 2
> ---------------------------------------------------------------------------
> <type 'exceptions.RuntimeError'>          Traceback (most recent call last)
>
> /home/faltet/python.nobackup/numpy/<ipython console> in <module>()
>
> <type 'exceptions.RuntimeError'>: array is not writeable
>
> In [105]: f4.flags.writeable = True
>
> In [106]: f4[2] = 2
>
> In [107]: f4
> Out[107]: array([  2.60561966e+20,   8.94319890e-39,   2.00000000e+00], 
> dtype=float32)
>
>
> i.e. in an array built from ndarray, the default is that it has to be 
> read-only?
>   
It's not that the it's being built from ndarray, it's that the buffer 
that you are passing it is read only. In fact, I'd argue that allowing 
the writeable flag to be set to True in this case is actually a bug. 
Consider this slightly modified example:

     >>> a = "12345"*4
     >>> f4=numpy.ndarray(buffer=a, dtype="f4", shape=3)
     >>> f4[2] = 99
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    RuntimeError: array is not writeable
     >>> f4.flags.writeable = True
     >>> a
    '12345123451234512345'
     >>> f4.flags.writeable = True
     >>> f4[2] = 99
     >>> a
    '12345123\x00\x00\xc6B34512345'

The original, *immutable* string has been mutated. This could get you 
into real trouble in certain situations.

-tim

[Numpy-discussion] Non-writeable default for numpy.ndarray

[Francesc A. <fa...@ca...>]

Hello,

Is the next a bug a feature?

In [102]: f4=3Dnumpy.ndarray(buffer=3D"a\x00b"*4, dtype=3D"f4", shape=3D3)

In [103]: f4
Out[103]: array([  2.60561966e+20,   8.94319890e-39,   5.92050103e+20],=20
dtype=3Dfloat32)

In [104]: f4[2] =3D 2
=2D------------------------------------------------------------------------=
=2D-
<type 'exceptions.RuntimeError'>          Traceback (most recent call last)

/home/faltet/python.nobackup/numpy/<ipython console> in <module>()

<type 'exceptions.RuntimeError'>: array is not writeable

In [105]: f4.flags.writeable =3D True

In [106]: f4[2] =3D 2

In [107]: f4
Out[107]: array([  2.60561966e+20,   8.94319890e-39,   2.00000000e+00],=20
dtype=3Dfloat32)


i.e. in an array built from ndarray, the default is that it has to be=20
read-only?


=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

[Numpy-discussion] Incorrect removal of NULL char in buffers

[Francesc A. <fa...@ca...>]

Hi,

I'm trying to build-up numpy arrays coming from buffers, and I'm getting a=
=20
somewhat unexpected result.

=46irst, for numeric values, everything seems ok (i.e. the NULL character i=
s=20
correctly interpretated), and works equally for both numarray and numpy:

In [98]: numarray.array("a\x00b"*4, dtype=3D'Float32',shape=3D3)
Out[98]: array([  2.60561966e+20,   8.94319890e-39,   5.92050103e+20],=20
type=3DFloat32)

In [99]: numpy.ndarray(buffer=3D"a\x00b"*4, dtype=3D'Float32',shape=3D3)
Out[99]: array([  2.60561966e+20,   8.94319890e-39,   5.92050103e+20],=20
dtype=3Dfloat32)

However, for string values, numpy seems to work in a strange way.=20
The numarray have an expected behaviour, IMO:

In [100]: numarray.strings.array(buffer=3D"a\x00b"*4, itemsize=3D4, shape=
=3D3)
Out[100]: CharArray(['a', '', 'ba']) =20

but numpy  haven't:

In [101]: numpy.ndarray(buffer=3D"a\x00b"*4, dtype=3D"S4", shape=3D3)
Out[101]:
array([aba, ba, bab],
      dtype=3D'|S4')

i.e. it seems like numpy is striping-off NULL chars before building the obj=
ect=20
and I don't think this is correct.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"