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

2006-10-01 Thread Francesc Altet
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.phpp=sourceforgeCID=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

2006-09-29 Thread Tim Hochberg
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.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 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





-
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.phpp=sourceforgeCID=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

2006-09-29 Thread Francesc Altet
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 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.

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.phpp=sourceforgeCID=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

2006-09-29 Thread Travis Oliphant
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.phpp=sourceforgeCID=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

2006-09-29 Thread Tim Hochberg
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.phpp=sourceforgeCID=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

2006-09-29 Thread Travis Oliphant
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.phpp=sourceforgeCID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion