Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
El dv 29 de 09 del 2006 a les 16:27 -0600, en/na Travis Oliphant va escriure: > 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. 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! -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-" - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
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 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
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 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
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 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
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 = "12345"*4 > >>> f4=numpy.ndarray(buffer=a, dtype="f4", shape=3) > >>> f4[2] = 99 > > Traceback (most recent call last): > File "", 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. I see. Thanks for the explanation. -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-" - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-writeable default for numpy.ndarray
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 > --- > Traceback (most recent call last) > > /home/faltet/python.nobackup/numpy/ in () > > : 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.e+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 "", 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 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] Non-writeable default for numpy.ndarray
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 --- Traceback (most recent call last) /home/faltet/python.nobackup/numpy/ in () : 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.e+00], dtype=float32) i.e. in an array built from ndarray, the default is that it has to be read-only? -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-" - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion