diff options
Diffstat (limited to 'numpy/doc')
| -rw-r--r-- | numpy/doc/basics.py | 39 | ||||
| -rw-r--r-- | numpy/doc/byteswapping.py | 20 | ||||
| -rw-r--r-- | numpy/doc/indexing.py | 4 |
3 files changed, 52 insertions, 11 deletions
diff --git a/numpy/doc/basics.py b/numpy/doc/basics.py index c87a40ccd..61f5bf4ef 100644 --- a/numpy/doc/basics.py +++ b/numpy/doc/basics.py @@ -260,6 +260,45 @@ identical behaviour between arrays and scalars, irrespective of whether the value is inside an array or not. NumPy scalars also have many of the same methods arrays do. +Overflow Errors +=============== + +The fixed size of NumPy numeric types may cause overflow errors when a value +requires more memory than available in the data type. For example, +`numpy.power` evaluates ``100 * 10 ** 8`` correctly for 64-bit integers, +but gives 1874919424 (incorrect) for a 32-bit integer. + + >>> np.power(100, 8, dtype=np.int64) + 10000000000000000 + >>> np.power(100, 8, dtype=np.int32) + 1874919424 + +The behaviour of NumPy and Python integer types differs significantly for +integer overflows and may confuse users expecting NumPy integers to behave +similar to Python's ``int``. Unlike NumPy, the size of Python's ``int`` is +flexible. This means Python integers may expand to accomodate any integer and +will not overflow. + +NumPy provides `numpy.iinfo` and `numpy.finfo` to verify the +minimum or maximum values of NumPy integer and floating point values +respectively :: + + >>> np.iinfo(np.int) # Bounds of the default integer on this system. + iinfo(min=-9223372036854775808, max=9223372036854775807, dtype=int64) + >>> np.iinfo(np.int32) # Bounds of a 32-bit integer + iinfo(min=-2147483648, max=2147483647, dtype=int32) + >>> np.iinfo(np.int64) # Bounds of a 64-bit integer + iinfo(min=-9223372036854775808, max=9223372036854775807, dtype=int64) + +If 64-bit integers are still too small the result may be cast to a +floating point number. Floating point numbers offer a larger, but inexact, +range of possible values. + + >>> np.power(100, 100, dtype=np.int64) # Incorrect even with 64-bit int + 0 + >>> np.power(100, 100, dtype=np.float64) + 1e+200 + Extended Precision ================== diff --git a/numpy/doc/byteswapping.py b/numpy/doc/byteswapping.py index f9491ed43..7a749c8d5 100644 --- a/numpy/doc/byteswapping.py +++ b/numpy/doc/byteswapping.py @@ -31,16 +31,16 @@ Let's say the two integers were in fact 1 and 770. Because 770 = 256 * 3 + 2, the 4 bytes in memory would contain respectively: 0, 1, 3, 2. The bytes I have loaded from the file would have these contents: ->>> big_end_str = chr(0) + chr(1) + chr(3) + chr(2) ->>> big_end_str -'\\x00\\x01\\x03\\x02' +>>> big_end_buffer = bytearray([0,1,3,2]) +>>> big_end_buffer +bytearray(b'\\x00\\x01\\x03\\x02') We might want to use an ``ndarray`` to access these integers. In that case, we can create an array around this memory, and tell numpy that there are two integers, and that they are 16 bit and big-endian: >>> import numpy as np ->>> big_end_arr = np.ndarray(shape=(2,),dtype='>i2', buffer=big_end_str) +>>> big_end_arr = np.ndarray(shape=(2,),dtype='>i2', buffer=big_end_buffer) >>> big_end_arr[0] 1 >>> big_end_arr[1] @@ -53,7 +53,7 @@ integer, the dtype string would be ``<u4``. In fact, why don't we try that? ->>> little_end_u4 = np.ndarray(shape=(1,),dtype='<u4', buffer=big_end_str) +>>> little_end_u4 = np.ndarray(shape=(1,),dtype='<u4', buffer=big_end_buffer) >>> little_end_u4[0] == 1 * 256**1 + 3 * 256**2 + 2 * 256**3 True @@ -97,7 +97,7 @@ Data and dtype endianness don't match, change dtype to match data We make something where they don't match: ->>> wrong_end_dtype_arr = np.ndarray(shape=(2,),dtype='<i2', buffer=big_end_str) +>>> wrong_end_dtype_arr = np.ndarray(shape=(2,),dtype='<i2', buffer=big_end_buffer) >>> wrong_end_dtype_arr[0] 256 @@ -110,7 +110,7 @@ the correct endianness: Note the array has not changed in memory: ->>> fixed_end_dtype_arr.tobytes() == big_end_str +>>> fixed_end_dtype_arr.tobytes() == big_end_buffer True Data and type endianness don't match, change data to match dtype @@ -126,7 +126,7 @@ that needs a certain byte ordering. Now the array *has* changed in memory: ->>> fixed_end_mem_arr.tobytes() == big_end_str +>>> fixed_end_mem_arr.tobytes() == big_end_buffer False Data and dtype endianness match, swap data and dtype @@ -140,7 +140,7 @@ the previous operations: >>> swapped_end_arr = big_end_arr.byteswap().newbyteorder() >>> swapped_end_arr[0] 1 ->>> swapped_end_arr.tobytes() == big_end_str +>>> swapped_end_arr.tobytes() == big_end_buffer False An easier way of casting the data to a specific dtype and byte ordering @@ -149,7 +149,7 @@ can be achieved with the ndarray astype method: >>> swapped_end_arr = big_end_arr.astype('<i2') >>> swapped_end_arr[0] 1 ->>> swapped_end_arr.tobytes() == big_end_str +>>> swapped_end_arr.tobytes() == big_end_buffer False """ diff --git a/numpy/doc/indexing.py b/numpy/doc/indexing.py index 087a688bc..f80d6c29e 100644 --- a/numpy/doc/indexing.py +++ b/numpy/doc/indexing.py @@ -93,7 +93,9 @@ well. A few examples illustrates best: :: [21, 24, 27]]) Note that slices of arrays do not copy the internal array data but -only produce new views of the original data. +only produce new views of the original data. This is different from +list or tuple slicing and an explicit ``copy()`` is recommended if +the original data is not required anymore. It is possible to index arrays with other arrays for the purposes of selecting lists of values out of arrays into new arrays. There are |
