tmp
/
pip-install-ghxuqwgs
/numpy_78e94bf2b6094bf9a1f3d92042f9bf46
/doc
/source
/reference
/arrays.scalars.rst
| .. _arrays.scalars: | |
| ******* | |
| Scalars | |
| ******* | |
| .. currentmodule:: numpy | |
| Python defines only one type of a particular data class (there is only | |
| one integer type, one floating-point type, etc.). This can be | |
| convenient in applications that don't need to be concerned with all | |
| the ways data can be represented in a computer. For scientific | |
| computing, however, more control is often needed. | |
| In NumPy, there are 24 new fundamental Python types to describe | |
| different types of scalars. These type descriptors are mostly based on | |
| the types available in the C language that CPython is written in, with | |
| several additional types compatible with Python's types. | |
| Array scalars have the same attributes and methods as :class:`ndarrays | |
| <ndarray>`. [#]_ This allows one to treat items of an array partly on | |
| the same footing as arrays, smoothing out rough edges that result when | |
| mixing scalar and array operations. | |
| Array scalars live in a hierarchy (see the Figure below) of data | |
| types. They can be detected using the hierarchy: For example, | |
| ``isinstance(val, np.generic)`` will return :const:`True` if *val* is | |
| an array scalar object. Alternatively, what kind of array scalar is | |
| present can be determined using other members of the data type | |
| hierarchy. Thus, for example ``isinstance(val, np.complexfloating)`` | |
| will return :const:`True` if *val* is a complex valued type, while | |
| :const:`isinstance(val, np.flexible)` will return true if *val* is one | |
| of the flexible itemsize array types (:class:`string`, | |
| :class:`unicode`, :class:`void`). | |
| .. figure:: figures/dtype-hierarchy.png | |
| **Figure:** Hierarchy of type objects representing the array data | |
| types. Not shown are the two integer types :class:`intp` and | |
| :class:`uintp` which just point to the integer type that holds a | |
| pointer for the platform. All the number types can be obtained | |
| using bit-width names as well. | |
| .. [#] However, array scalars are immutable, so none of the array | |
| scalar attributes are settable. | |
| .. _arrays.scalars.character-codes: | |
| .. _arrays.scalars.built-in: | |
| Built-in scalar types | |
| ===================== | |
| The built-in scalar types are shown below. Along with their (mostly) | |
| C-derived names, the integer, float, and complex data-types are also | |
| available using a bit-width convention so that an array of the right | |
| size can always be ensured (e.g. :class:`int8`, :class:`float64`, | |
| :class:`complex128`). Two aliases (:class:`intp` and :class:`uintp`) | |
| pointing to the integer type that is sufficiently large to hold a C pointer | |
| are also provided. The C-like names are associated with character codes, | |
| which are shown in the table. Use of the character codes, however, | |
| is discouraged. | |
| Some of the scalar types are essentially equivalent to fundamental | |
| Python types and therefore inherit from them as well as from the | |
| generic array scalar type: | |
| ==================== ==================== | |
| Array scalar type Related Python type | |
| ==================== ==================== | |
| :class:`int_` :class:`IntType` (Python 2 only) | |
| :class:`float_` :class:`FloatType` | |
| :class:`complex_` :class:`ComplexType` | |
| :class:`str_` :class:`StringType` | |
| :class:`unicode_` :class:`UnicodeType` | |
| ==================== ==================== | |
| The :class:`bool_` data type is very similar to the Python | |
| :class:`BooleanType` but does not inherit from it because Python's | |
| :class:`BooleanType` does not allow itself to be inherited from, and | |
| on the C-level the size of the actual bool data is not the same as a | |
| Python Boolean scalar. | |
| .. warning:: | |
| The :class:`bool_` type is not a subclass of the :class:`int_` type | |
| (the :class:`bool_` is not even a number type). This is different | |
| than Python's default implementation of :class:`bool` as a | |
| sub-class of int. | |
| .. warning:: | |
| The :class:`int_` type does **not** inherit from the | |
| :class:`int` built-in under Python 3, because type :class:`int` is no | |
| longer a fixed-width integer type. | |
| .. tip:: The default data type in Numpy is :class:`float_`. | |
| In the tables below, ``platform?`` means that the type may not be | |
| available on all platforms. Compatibility with different C or Python | |
| types is indicated: two types are compatible if their data is of the | |
| same size and interpreted in the same way. | |
| Booleans: | |
| =================== ============================= =============== | |
| Type Remarks Character code | |
| =================== ============================= =============== | |
| :class:`bool_` compatible: Python bool ``'?'`` | |
| :class:`bool8` 8 bits | |
| =================== ============================= =============== | |
| Integers: | |
| =================== ============================= =============== | |
| :class:`byte` compatible: C char ``'b'`` | |
| :class:`short` compatible: C short ``'h'`` | |
| :class:`intc` compatible: C int ``'i'`` | |
| :class:`int_` compatible: Python int ``'l'`` | |
| :class:`longlong` compatible: C long long ``'q'`` | |
| :class:`intp` large enough to fit a pointer ``'p'`` | |
| :class:`int8` 8 bits | |
| :class:`int16` 16 bits | |
| :class:`int32` 32 bits | |
| :class:`int64` 64 bits | |
| =================== ============================= =============== | |
| Unsigned integers: | |
| =================== ============================= =============== | |
| :class:`ubyte` compatible: C unsigned char ``'B'`` | |
| :class:`ushort` compatible: C unsigned short ``'H'`` | |
| :class:`uintc` compatible: C unsigned int ``'I'`` | |
| :class:`uint` compatible: Python int ``'L'`` | |
| :class:`ulonglong` compatible: C long long ``'Q'`` | |
| :class:`uintp` large enough to fit a pointer ``'P'`` | |
| :class:`uint8` 8 bits | |
| :class:`uint16` 16 bits | |
| :class:`uint32` 32 bits | |
| :class:`uint64` 64 bits | |
| =================== ============================= =============== | |
| Floating-point numbers: | |
| =================== ============================= =============== | |
| :class:`half` ``'e'`` | |
| :class:`single` compatible: C float ``'f'`` | |
| :class:`double` compatible: C double | |
| :class:`float_` compatible: Python float ``'d'`` | |
| :class:`longfloat` compatible: C long float ``'g'`` | |
| :class:`float16` 16 bits | |
| :class:`float32` 32 bits | |
| :class:`float64` 64 bits | |
| :class:`float96` 96 bits, platform? | |
| :class:`float128` 128 bits, platform? | |
| =================== ============================= =============== | |
| Complex floating-point numbers: | |
| =================== ============================= =============== | |
| :class:`csingle` ``'F'`` | |
| :class:`complex_` compatible: Python complex ``'D'`` | |
| :class:`clongfloat` ``'G'`` | |
| :class:`complex64` two 32-bit floats | |
| :class:`complex128` two 64-bit floats | |
| :class:`complex192` two 96-bit floats, | |
| platform? | |
| :class:`complex256` two 128-bit floats, | |
| platform? | |
| =================== ============================= =============== | |
| Any Python object: | |
| =================== ============================= =============== | |
| :class:`object_` any Python object ``'O'`` | |
| =================== ============================= =============== | |
| .. note:: | |
| The data actually stored in :term:`object arrays <object array>` | |
| (*i.e.*, arrays having dtype :class:`object_`) are references to | |
| Python objects, not the objects themselves. Hence, object arrays | |
| behave more like usual Python :class:`lists <list>`, in the sense | |
| that their contents need not be of the same Python type. | |
| The object type is also special because an array containing | |
| :class:`object_` items does not return an :class:`object_` object | |
| on item access, but instead returns the actual object that | |
| the array item refers to. | |
| The following data types are :term:`flexible`. They have no predefined | |
| size: the data they describe can be of different length in different | |
| arrays. (In the character codes ``#`` is an integer denoting how many | |
| elements the data type consists of.) | |
| =================== ============================= ======== | |
| :class:`str_` compatible: Python str ``'S#'`` | |
| :class:`unicode_` compatible: Python unicode ``'U#'`` | |
| :class:`void` ``'V#'`` | |
| =================== ============================= ======== | |
| .. warning:: | |
| Numeric Compatibility: If you used old typecode characters in your | |
| Numeric code (which was never recommended), you will need to change | |
| some of them to the new characters. In particular, the needed | |
| changes are ``c -> S1``, ``b -> B``, ``1 -> b``, ``s -> h``, ``w -> | |
| H``, and ``u -> I``. These changes make the type character | |
| convention more consistent with other Python modules such as the | |
| :mod:`struct` module. | |
| Attributes | |
| ========== | |
| The array scalar objects have an :obj:`array priority | |
| <__array_priority__>` of :cdata:`NPY_SCALAR_PRIORITY` | |
| (-1,000,000.0). They also do not (yet) have a :attr:`ctypes <ndarray.ctypes>` | |
| attribute. Otherwise, they share the same attributes as arrays: | |
| .. autosummary:: | |
| :toctree: generated/ | |
| generic.flags | |
| generic.shape | |
| generic.strides | |
| generic.ndim | |
| generic.data | |
| generic.size | |
| generic.itemsize | |
| generic.base | |
| generic.dtype | |
| generic.real | |
| generic.imag | |
| generic.flat | |
| generic.T | |
| generic.__array_interface__ | |
| generic.__array_struct__ | |
| generic.__array_priority__ | |
| generic.__array_wrap__ | |
| Indexing | |
| ======== | |
| .. seealso:: :ref:`arrays.indexing`, :ref:`arrays.dtypes` | |
| Array scalars can be indexed like 0-dimensional arrays: if *x* is an | |
| array scalar, | |
| - ``x[()]`` returns a 0-dimensional :class:`ndarray` | |
| - ``x['field-name']`` returns the array scalar in the field *field-name*. | |
| (*x* can have fields, for example, when it corresponds to a record data type.) | |
| Methods | |
| ======= | |
| Array scalars have exactly the same methods as arrays. The default | |
| behavior of these methods is to internally convert the scalar to an | |
| equivalent 0-dimensional array and to call the corresponding array | |
| method. In addition, math operations on array scalars are defined so | |
| that the same hardware flags are set and used to interpret the results | |
| as for :ref:`ufunc <ufuncs>`, so that the error state used for ufuncs | |
| also carries over to the math on array scalars. | |
| The exceptions to the above rules are given below: | |
| .. autosummary:: | |
| :toctree: generated/ | |
| generic | |
| generic.__array__ | |
| generic.__array_wrap__ | |
| generic.squeeze | |
| generic.byteswap | |
| generic.__reduce__ | |
| generic.__setstate__ | |
| generic.setflags | |
| Defining new types | |
| ================== | |
| There are two ways to effectively define a new array scalar type | |
| (apart from composing record :ref:`dtypes <arrays.dtypes>` from the built-in | |
| scalar types): One way is to simply subclass the :class:`ndarray` and | |
| overwrite the methods of interest. This will work to a degree, but | |
| internally certain behaviors are fixed by the data type of the array. | |
| To fully customize the data type of an array you need to define a new | |
| data-type, and register it with NumPy. Such new types can only be | |
| defined in C, using the :ref:`Numpy C-API <c-api>`. | |