github.com/jingcheng-WU/gonum@v0.9.1-0.20210323123734-f1a2a11a8f7b/mat/doc.go (about)

     1  // Copyright ©2015 The Gonum Authors. All rights reserved.
     2  // Use of this source code is governed by a BSD-style
     3  // license that can be found in the LICENSE file.
     4  
     5  // Package mat provides implementations of float64 and complex128 matrix
     6  // structures and linear algebra operations on them.
     7  //
     8  // Overview
     9  //
    10  // This section provides a quick overview of the mat package. The following
    11  // sections provide more in depth commentary.
    12  //
    13  // mat provides:
    14  //  - Interfaces for Matrix classes (Matrix, Symmetric, Triangular)
    15  //  - Concrete implementations (Dense, SymDense, TriDense, VecDense)
    16  //  - Methods and functions for using matrix data (Add, Trace, SymRankOne)
    17  //  - Types for constructing and using matrix factorizations (QR, LU, etc.)
    18  //  - The complementary types for complex matrices, CMatrix, CSymDense, etc.
    19  // In the documentation below, we use "matrix" as a short-hand for all of
    20  // the FooDense types implemented in this package. We use "Matrix" to
    21  // refer to the Matrix interface.
    22  //
    23  // A matrix may be constructed through the corresponding New function. If no
    24  // backing array is provided the matrix will be initialized to all zeros.
    25  //  // Allocate a zeroed real matrix of size 3×5
    26  //  zero := mat.NewDense(3, 5, nil)
    27  // If a backing data slice is provided, the matrix will have those elements.
    28  // All matrices are stored in row-major format and users should consider
    29  // this when expressing matrix arithmetic to ensure optimal performance.
    30  //  // Generate a 6×6 matrix of random values.
    31  //  data := make([]float64, 36)
    32  //  for i := range data {
    33  //  	data[i] = rand.NormFloat64()
    34  //  }
    35  //  a := mat.NewDense(6, 6, data)
    36  // Operations involving matrix data are implemented as functions when the values
    37  // of the matrix remain unchanged
    38  //  tr := mat.Trace(a)
    39  // and are implemented as methods when the operation modifies the receiver.
    40  //  zero.Copy(a)
    41  // Note that the input arguments to most functions and methods are interfaces
    42  // rather than concrete types `func Trace(Matrix)` rather than
    43  // `func Trace(*Dense)` allowing flexible use of internal and external
    44  // Matrix types.
    45  //
    46  // When a matrix is the destination or receiver for a function or method,
    47  // the operation will panic if the matrix is not the correct size.
    48  // An exception to this is when the destination is empty (see below).
    49  //
    50  // Empty matrix
    51  //
    52  // An empty matrix is one that has zero size. Empty matrices are used to allow
    53  // the destination of a matrix operation to assume the correct size automatically.
    54  // This operation will re-use the backing data, if available, or will allocate
    55  // new data if necessary. The IsEmpty method returns whether the given matrix
    56  // is empty. The zero-value of a matrix is empty, and is useful for easily
    57  // getting the result of matrix operations.
    58  //  var c mat.Dense // construct a new zero-value matrix
    59  //  c.Mul(a, a)     // c is automatically adjusted to be the right size
    60  // The Reset method can be used to revert a matrix to an empty matrix.
    61  // Reset should not be used when multiple different matrices share the same backing
    62  // data slice. This can cause unexpected data modifications after being resized.
    63  // An empty matrix can not be sliced even if it does have an adequately sized
    64  // backing data slice, but can be expanded using its Grow method if it exists.
    65  //
    66  // The Matrix Interfaces
    67  //
    68  // The Matrix interface is the common link between the concrete types of real
    69  // matrices. The Matrix interface is defined by three functions: Dims, which
    70  // returns the dimensions of the Matrix, At, which returns the element in the
    71  // specified location, and T for returning a Transpose (discussed later). All of
    72  // the matrix types can perform these behaviors and so implement the interface.
    73  // Methods and functions are designed to use this interface, so in particular the method
    74  //  func (m *Dense) Mul(a, b Matrix)
    75  // constructs a *Dense from the result of a multiplication with any Matrix types,
    76  // not just *Dense. Where more restrictive requirements must be met, there are also
    77  // additional interfaces like Symmetric and Triangular. For example, in
    78  //  func (s *SymDense) AddSym(a, b Symmetric)
    79  // the Symmetric interface guarantees a symmetric result.
    80  //
    81  // The CMatrix interface plays the same role for complex matrices. The difference
    82  // is that the CMatrix type has the H method instead T, for returning the conjugate
    83  // transpose.
    84  //
    85  // (Conjugate) Transposes
    86  //
    87  // The T method is used for transposition on real matrices, and H is used for
    88  // conjugate transposition on complex matrices. For example, c.Mul(a.T(), b) computes
    89  // c = aᵀ * b. The mat types implement this method implicitly —
    90  // see the Transpose and Conjugate types for more details. Note that some
    91  // operations have a transpose as part of their definition, as in *SymDense.SymOuterK.
    92  //
    93  // Matrix Factorization
    94  //
    95  // Matrix factorizations, such as the LU decomposition, typically have their own
    96  // specific data storage, and so are each implemented as a specific type. The
    97  // factorization can be computed through a call to Factorize
    98  //  var lu mat.LU
    99  //  lu.Factorize(a)
   100  // The elements of the factorization can be extracted through methods on the
   101  // factorized type, for example *LU.UTo. The factorization types can also be used
   102  // directly, as in *Cholesky.SolveTo. Some factorizations can be updated directly,
   103  // without needing to update the original matrix and refactorize, for example with
   104  // *LU.RankOne.
   105  //
   106  // BLAS and LAPACK
   107  //
   108  // BLAS and LAPACK are the standard APIs for linear algebra routines. Many
   109  // operations in mat are implemented using calls to the wrapper functions
   110  // in gonum/blas/blas64 and gonum/lapack/lapack64 and their complex equivalents.
   111  // By default, blas64 and lapack64 call the native Go implementations of the
   112  // routines. Alternatively, it is possible to use C-based implementations of the
   113  // APIs through the respective cgo packages and the wrapper packages' "Use"
   114  // functions. The Go implementation of LAPACK makes calls through blas64, so if
   115  // a cgo BLAS implementation is registered, the lapack64 calls will be partially
   116  // executed in Go and partially executed in C.
   117  //
   118  // Type Switching
   119  //
   120  // The Matrix abstraction enables efficiency as well as interoperability. Go's
   121  // type reflection capabilities are used to choose the most efficient routine
   122  // given the specific concrete types. For example, in
   123  //  c.Mul(a, b)
   124  // if a and b both implement RawMatrixer, that is, they can be represented as a
   125  // blas64.General, blas64.Gemm (general matrix multiplication) is called, while
   126  // instead if b is a RawSymmetricer blas64.Symm is used (general-symmetric
   127  // multiplication), and if b is a *VecDense blas64.Gemv is used.
   128  //
   129  // There are many possible type combinations and special cases. No specific guarantees
   130  // are made about the performance of any method, and in particular, note that an
   131  // abstract matrix type may be copied into a concrete type of the corresponding
   132  // value. If there are specific special cases that are needed, please submit a
   133  // pull-request or file an issue.
   134  //
   135  // Invariants
   136  //
   137  // Matrix input arguments to package functions are never directly modified. If an
   138  // operation changes Matrix data, the mutated matrix will be the receiver of a
   139  // method, or will be the first, dst, argument to a method named with a To suffix.
   140  //
   141  // For convenience, a matrix may be used as both a receiver and as an input, e.g.
   142  //  a.Pow(a, 6)
   143  //  v.SolveVec(a.T(), v)
   144  // though in many cases this will cause an allocation (see Element Aliasing).
   145  // An exception to this rule is Copy, which does not allow a.Copy(a.T()).
   146  //
   147  // Element Aliasing
   148  //
   149  // Most methods in mat modify receiver data. It is forbidden for the modified
   150  // data region of the receiver to overlap the used data area of the input
   151  // arguments. The exception to this rule is when the method receiver is equal to one
   152  // of the input arguments, as in the a.Pow(a, 6) call above, or its implicit transpose.
   153  //
   154  // This prohibition is to help avoid subtle mistakes when the method needs to read
   155  // from and write to the same data region. There are ways to make mistakes using the
   156  // mat API, and mat functions will detect and complain about those.
   157  // There are many ways to make mistakes by excursion from the mat API via
   158  // interaction with raw matrix values.
   159  //
   160  // If you need to read the rest of this section to understand the behavior of
   161  // your program, you are being clever. Don't be clever. If you must be clever,
   162  // blas64 and lapack64 may be used to call the behavior directly.
   163  //
   164  // mat will use the following rules to detect overlap between the receiver and one
   165  // of the inputs:
   166  //  - the input implements one of the Raw methods, and
   167  //  - the address ranges of the backing data slices overlap, and
   168  //  - the strides differ or there is an overlap in the used data elements.
   169  // If such an overlap is detected, the method will panic.
   170  //
   171  // The following cases will not panic:
   172  //  - the data slices do not overlap,
   173  //  - there is pointer identity between the receiver and input values after
   174  //    the value has been untransposed if necessary.
   175  //
   176  // mat will not attempt to detect element overlap if the input does not implement a
   177  // Raw method. Method behavior is undefined if there is undetected overlap.
   178  //
   179  package mat // import "github.com/jingcheng-WU/gonum/mat"