misc.py 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228
  1. """
  2. =============
  3. Miscellaneous
  4. =============
  5. IEEE 754 Floating Point Special Values
  6. --------------------------------------
  7. Special values defined in numpy: nan, inf,
  8. NaNs can be used as a poor-man's mask (if you don't care what the
  9. original value was)
  10. Note: cannot use equality to test NaNs. E.g.: ::
  11. >>> myarr = np.array([1., 0., np.nan, 3.])
  12. >>> np.nonzero(myarr == np.nan)
  13. (array([], dtype=int64),)
  14. >>> np.nan == np.nan # is always False! Use special numpy functions instead.
  15. False
  16. >>> myarr[myarr == np.nan] = 0. # doesn't work
  17. >>> myarr
  18. array([ 1., 0., NaN, 3.])
  19. >>> myarr[np.isnan(myarr)] = 0. # use this instead find
  20. >>> myarr
  21. array([ 1., 0., 0., 3.])
  22. Other related special value functions: ::
  23. isinf(): True if value is inf
  24. isfinite(): True if not nan or inf
  25. nan_to_num(): Map nan to 0, inf to max float, -inf to min float
  26. The following corresponds to the usual functions except that nans are excluded
  27. from the results: ::
  28. nansum()
  29. nanmax()
  30. nanmin()
  31. nanargmax()
  32. nanargmin()
  33. >>> x = np.arange(10.)
  34. >>> x[3] = np.nan
  35. >>> x.sum()
  36. nan
  37. >>> np.nansum(x)
  38. 42.0
  39. How numpy handles numerical exceptions
  40. --------------------------------------
  41. The default is to ``'warn'`` for ``invalid``, ``divide``, and ``overflow``
  42. and ``'ignore'`` for ``underflow``. But this can be changed, and it can be
  43. set individually for different kinds of exceptions. The different behaviors
  44. are:
  45. - 'ignore' : Take no action when the exception occurs.
  46. - 'warn' : Print a `RuntimeWarning` (via the Python `warnings` module).
  47. - 'raise' : Raise a `FloatingPointError`.
  48. - 'call' : Call a function specified using the `seterrcall` function.
  49. - 'print' : Print a warning directly to ``stdout``.
  50. - 'log' : Record error in a Log object specified by `seterrcall`.
  51. These behaviors can be set for all kinds of errors or specific ones:
  52. - all : apply to all numeric exceptions
  53. - invalid : when NaNs are generated
  54. - divide : divide by zero (for integers as well!)
  55. - overflow : floating point overflows
  56. - underflow : floating point underflows
  57. Note that integer divide-by-zero is handled by the same machinery.
  58. These behaviors are set on a per-thread basis.
  59. Examples
  60. --------
  61. ::
  62. >>> oldsettings = np.seterr(all='warn')
  63. >>> np.zeros(5,dtype=np.float32)/0.
  64. invalid value encountered in divide
  65. >>> j = np.seterr(under='ignore')
  66. >>> np.array([1.e-100])**10
  67. >>> j = np.seterr(invalid='raise')
  68. >>> np.sqrt(np.array([-1.]))
  69. FloatingPointError: invalid value encountered in sqrt
  70. >>> def errorhandler(errstr, errflag):
  71. ... print("saw stupid error!")
  72. >>> np.seterrcall(errorhandler)
  73. <function err_handler at 0x...>
  74. >>> j = np.seterr(all='call')
  75. >>> np.zeros(5, dtype=np.int32)/0
  76. FloatingPointError: invalid value encountered in divide
  77. saw stupid error!
  78. >>> j = np.seterr(**oldsettings) # restore previous
  79. ... # error-handling settings
  80. Interfacing to C
  81. ----------------
  82. Only a survey of the choices. Little detail on how each works.
  83. 1) Bare metal, wrap your own C-code manually.
  84. - Plusses:
  85. - Efficient
  86. - No dependencies on other tools
  87. - Minuses:
  88. - Lots of learning overhead:
  89. - need to learn basics of Python C API
  90. - need to learn basics of numpy C API
  91. - need to learn how to handle reference counting and love it.
  92. - Reference counting often difficult to get right.
  93. - getting it wrong leads to memory leaks, and worse, segfaults
  94. - API will change for Python 3.0!
  95. 2) Cython
  96. - Plusses:
  97. - avoid learning C API's
  98. - no dealing with reference counting
  99. - can code in pseudo python and generate C code
  100. - can also interface to existing C code
  101. - should shield you from changes to Python C api
  102. - has become the de-facto standard within the scientific Python community
  103. - fast indexing support for arrays
  104. - Minuses:
  105. - Can write code in non-standard form which may become obsolete
  106. - Not as flexible as manual wrapping
  107. 3) ctypes
  108. - Plusses:
  109. - part of Python standard library
  110. - good for interfacing to existing sharable libraries, particularly
  111. Windows DLLs
  112. - avoids API/reference counting issues
  113. - good numpy support: arrays have all these in their ctypes
  114. attribute: ::
  115. a.ctypes.data a.ctypes.get_strides
  116. a.ctypes.data_as a.ctypes.shape
  117. a.ctypes.get_as_parameter a.ctypes.shape_as
  118. a.ctypes.get_data a.ctypes.strides
  119. a.ctypes.get_shape a.ctypes.strides_as
  120. - Minuses:
  121. - can't use for writing code to be turned into C extensions, only a wrapper
  122. tool.
  123. 4) SWIG (automatic wrapper generator)
  124. - Plusses:
  125. - around a long time
  126. - multiple scripting language support
  127. - C++ support
  128. - Good for wrapping large (many functions) existing C libraries
  129. - Minuses:
  130. - generates lots of code between Python and the C code
  131. - can cause performance problems that are nearly impossible to optimize
  132. out
  133. - interface files can be hard to write
  134. - doesn't necessarily avoid reference counting issues or needing to know
  135. API's
  136. 5) scipy.weave
  137. - Plusses:
  138. - can turn many numpy expressions into C code
  139. - dynamic compiling and loading of generated C code
  140. - can embed pure C code in Python module and have weave extract, generate
  141. interfaces and compile, etc.
  142. - Minuses:
  143. - Future very uncertain: it's the only part of Scipy not ported to Python 3
  144. and is effectively deprecated in favor of Cython.
  145. 6) Psyco
  146. - Plusses:
  147. - Turns pure python into efficient machine code through jit-like
  148. optimizations
  149. - very fast when it optimizes well
  150. - Minuses:
  151. - Only on intel (windows?)
  152. - Doesn't do much for numpy?
  153. Interfacing to Fortran:
  154. -----------------------
  155. The clear choice to wrap Fortran code is
  156. `f2py <https://docs.scipy.org/doc/numpy/f2py/>`_.
  157. Pyfort is an older alternative, but not supported any longer.
  158. Fwrap is a newer project that looked promising but isn't being developed any
  159. longer.
  160. Interfacing to C++:
  161. -------------------
  162. 1) Cython
  163. 2) CXX
  164. 3) Boost.python
  165. 4) SWIG
  166. 5) SIP (used mainly in PyQT)
  167. """
  168. from __future__ import division, absolute_import, print_function