You can subscribe to this list here.
2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
From: Lars B. <lar...@go...> - 2006-10-02 21:59:10
|
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 |
From: Lars B. <lar...@go...> - 2006-10-02 21:59:09
|
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 |
From: Travis O. <oli...@ee...> - 2006-10-02 21:53:21
|
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 |
From: Lars B. <lar...@go...> - 2006-10-02 21:28:22
|
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 |
From: Todd M. <jm...@st...> - 2006-10-02 19:04:34
|
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 |
From: Russell E. O. <ro...@ce...> - 2006-10-02 18:09:00
|
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 |
From: Jeno K. <per...@in...> - 2006-10-02 16:21:52
|
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 |
From: Lars B. <lar...@go...> - 2006-10-02 09:30:47
|
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 |
From: Lars B. <lar...@go...> - 2006-10-02 09:30:41
|
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 |
From: Emanuele O. <oli...@it...> - 2006-10-02 08:44:57
|
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 |
From: Kyle F. <kf...@co...> - 2006-10-02 02:32:29
|
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 |
From: Gael V. <gae...@no...> - 2006-10-01 19:42:52
|
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 |
From: Francesc A. <fa...@ca...> - 2006-10-01 11:49:46
|
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 "-" |
From: Robert K. <rob...@gm...> - 2006-09-30 01:01:52
|
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 |
From: Coatimundi <coa...@co...> - 2006-09-30 00:27:41
|
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! |
From: Travis O. <oli...@ee...> - 2006-09-29 22:27:12
|
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 |
From: Kyle F. <coa...@ho...> - 2006-09-29 21:22:31
|
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 |
From: Travis O. <oli...@ie...> - 2006-09-29 18:19:01
|
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 |
From: Robert K. <rob...@gm...> - 2006-09-29 17:28:46
|
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 |
From: Tim H. <tim...@ie...> - 2006-09-29 16:59:32
|
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 |
From: Travis O. <oli...@ie...> - 2006-09-29 16:55:24
|
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 |
From: Francesc A. <fa...@ca...> - 2006-09-29 16:44:17
|
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 "-" |
From: Tim H. <tim...@ie...> - 2006-09-29 16:12:36
|
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 |
From: Francesc A. <fa...@ca...> - 2006-09-29 15:23:33
|
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 "-" |
From: Francesc A. <fa...@ca...> - 2006-09-29 15:19:10
|
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 "-" |