Merge pull request #250 from ArnoStrouwen/LanguageTool

[skip ci] LanguageTool

Author: ChrisRackauckas

docs/src/advanced/developing.md

@@ -7,7 +7,7 @@ one of two ways:
 2. You can extend LinearSolve.jl's internal mechanisms.
 
 For developer ease, we highly recommend (2) as that will automatically make the
-caching API work. Thus this is the documentation for how to do that.
+caching API work. Thus, this is the documentation for how to do that.
 
 ## Developing New Linear Solvers with LinearSolve.jl Primitives
 
@@ -43,18 +43,18 @@ is what is called at `init` time to create the first `cacheval`. Note that this
 should match the type of the cache later used in `solve` as many algorithms, like
 those in OrdinaryDiffEq.jl, expect type-groundedness in the linear solver definitions.
 While there are cheaper ways to obtain this type for LU factorizations (specifically,
-`ArrayInterfaceCore.lu_instance(A)`), for a demonstration this just performs an
+`ArrayInterfaceCore.lu_instance(A)`), for a demonstration, this just performs an
 LU-factorization to get an `LU{T, Matrix{T}}` which it puts into the `cacheval`
-so its typed for future use.
+so it is typed for future use.
 
 After the `init_cacheval`, the only thing left to do is to define
 `SciMLBase.solve(cache::LinearCache, alg::MyLUFactorization)`. Many algorithms
-may use a lazy matrix-free representation of the operator `A`. Thus if the
+may use a lazy matrix-free representation of the operator `A`. Thus, if the
 algorithm requires a concrete matrix, like LU-factorization does, the algorithm
 should `convert(AbstractMatrix,cache.A)`. The flag `cache.isfresh` states whether
 `A` has changed since the last `solve`. Since we only need to factorize when
 `A` is new, the factorization part of the algorithm is done in a `if cache.isfresh`.
-`cache = set_cacheval(cache, fact)` puts the new factorization into the cache
+`cache = set_cacheval(cache, fact)` puts the new factorization into the cache,
 so it's updated for future solves. Then `y = ldiv!(cache.u, cache.cacheval, cache.b)`
 performs the solve and a linear solution is returned via
 `SciMLBase.build_linear_solution(alg,y,nothing,cache)`.

docs/src/basics/FAQ.md

@@ -1,13 +1,11 @@
 # Frequently Asked Questions
 
-Ask more questions.
-
 ## How is LinearSolve.jl compared to just using normal \, i.e. A\b?
 
 Check out [this video from JuliaCon 2022](https://www.youtube.com/watch?v=JWI34_w-yYw) which goes
-into detail on how and why LinearSolve.jl is able to be a more general and efficient interface.
+into detail on how and why LinearSolve.jl can be a more general and efficient interface.
 
-Note that if `\` is good enough for you, great! We still tend to use `\` in the REPL all of the time!
+Note that if `\` is good enough for you, great! We still tend to use `\` in the REPL all the time!
 However, if you're building a package, you may want to consider using LinearSolve.jl for the improved
 efficiency and ability to choose solvers.
 
@@ -27,16 +25,16 @@ a few ways:
    faster (in a platform and matrix-specific way).
 2. Standard approaches to handling linear solves re-allocate the pivoting vector each time. This leads to GC pauses that
    can slow down calculations. LinearSolve.jl has proper caches for fully preallocated no-GC workflows.
-3. LinearSolve.jl makes a lot of other optimizations, like factorization reuse and symbolic factorization reuse, automatic.
+3. LinearSolve.jl makes many other optimizations, like factorization reuse and symbolic factorization reuse, automatic.
    Many of these optimizations are not even possible from the high-level APIs of things like Python's major libraries and MATLAB.
 4. LinearSolve.jl has a much more extensive set of sparse matrix solvers, which is why you see a major difference (2x-10x) for sparse
    matrices. Which sparse matrix solver between KLU, UMFPACK, Pardiso, etc. is optimal depends a lot on matrix sizes, sparsity patterns,
    and threading overheads. LinearSolve.jl's heuristics handle these kinds of issues.
 
 ## How do I use IterativeSolvers solvers with a weighted tolerance vector?
 
-IterativeSolvers.jl computes the norm after the application of the left precondtioner
-`Pl`. Thus in order to use a vector tolerance `weights`, one can mathematically
+IterativeSolvers.jl computes the norm after the application of the left preconditioner
+`Pl`. Thus, in order to use a vector tolerance `weights`, one can mathematically
 hack the system via the following formulation:
 
 ```@example FAQPrec
@@ -57,7 +55,7 @@ sol = solve(prob,IterativeSolversJL_GMRES(),Pl=Pl,Pr=Pr)
 sol.u
 ```
 
-If you want to use a "real" preconditioner under the norm `weights`, then one
+If you want to use a “real” preconditioner under the norm `weights`, then one
 can use `ComposePreconditioner` to apply the preconditioner after the application
 of the weights like as follows:
 

docs/src/basics/Preconditioners.md

@@ -31,7 +31,7 @@ A two-sided preconditioned system is of the form:
 P_l^{-1}A P_r^{-1} (P_r u) = P_l^{-1}b
 ```
 
-By default, if no preconditioner is given the preconditioner is assumed to be
+By default, if no preconditioner is given, the preconditioner is assumed to be
 the identity ``I``.
 
 ### Using Preconditioners
@@ -99,8 +99,8 @@ The following preconditioners match the interface of LinearSolve.jl.
 - [LimitedLDLFactorizations.lldl](https://github.com/JuliaSmoothOptimizers/LimitedLDLFactorizations.jl):
   A limited-memory LDLᵀ factorization for symmetric matrices. Requires `A` as a
   `SparseMatrixCSC`. Applying `F = lldl(A); F.D .= abs.(F.D)` before usage as a preconditioner
-  makes the preconditioner symmetric postive definite and thus is required for Krylov methods which
+  makes the preconditioner symmetric positive definite and thus is required for Krylov methods which
   are specialized for symmetric linear systems.
 - [RandomizedPreconditioners.NystromPreconditioner](https://github.com/tjdiamandis/RandomizedPreconditioners.jl)
   A randomized sketching method for positive semidefinite matrices `A`. Builds a preconditioner ``P ≈ A + μ*I``
-  for the system ``(A + μ*I)x = b``
+  for the system ``(A + μ*I)x = b``.

docs/src/basics/common_solver_opts.md

@@ -1,7 +1,7 @@
 # Common Solver Options (Keyword Arguments for Solve)
 
 While many algorithms have specific arguments within their constructor,
-the keyword arguments for `solve` are common across all of the algorithms
+the keyword arguments for `solve` are common across all the algorithms
 in order to give composability. These are also the options taken at `init` time.
 The following are the options these algorithms take, along with their defaults.
 
@@ -23,5 +23,5 @@ solve completely. Error controls only apply to iterative solvers.
 - `abstol`: The absolute tolerance. Defaults to `√(eps(eltype(A)))`
 - `reltol`: The relative tolerance. Defaults to `√(eps(eltype(A)))`
 - `maxiters`: The number of iterations allowed. Defaults to `length(prob.b)`
-- `Pl,Pr`: The left and right preconditioners respectively. For more information
+- `Pl,Pr`: The left and right preconditioners, respectively. For more information,
   see [the Preconditioners page](@ref prec).

docs/src/solvers/solvers.md

@@ -7,7 +7,7 @@ Solves for ``Au=b`` in the problem defined by `prob` using the algorithm
 
 ## Recommended Methods
 
-The default algorithm `nothing` is good for choosing an algorithm that will work,
+The default algorithm `nothing` is good for picking an algorithm that will work,
 but one may need to change this to receive more performance or precision. If
 more precision is necessary, `QRFactorization()` and `SVDFactorization()` are
 the best choices, with SVD being the slowest but most precise.
@@ -29,7 +29,7 @@ with CPUs and GPUs, and thus is the generally preferred form for Krylov methods.
 
 Finally, a user can pass a custom function for handling the linear solve using
 `LinearSolveFunction()` if existing solvers are not optimally suited for their application.
-The interface is detailed [here](#passing-in-a-custom-linear-solver)
+The interface is detailed [here](#passing-in-a-custom-linear-solver).
 
 ## Full List of Methods
 
@@ -49,29 +49,29 @@ customized per-package, details given below describe a subset of important array
 (`Matrix`, `SparseMatrixCSC`, `CuMatrix`, etc.)
 
 - `LUFactorization(pivot=LinearAlgebra.RowMaximum())`: Julia's built in `lu`.
-  - On dense matrices this uses the current BLAS implementation of the user's computer
+  - On dense matrices, this uses the current BLAS implementation of the user's computer,
     which by default is OpenBLAS but will use MKL if the user does `using MKL` in their
     system.
-  - On sparse matrices this will use UMFPACK from SuiteSparse. Note that this will not
+  - On sparse matrices, this will use UMFPACK from SuiteSparse. Note that this will not
     cache the symbolic factorization.
-  - On CuMatrix it will use a CUDA-accelerated LU from CuSolver.
-  - On BandedMatrix and BlockBandedMatrix it will use a banded LU.
+  - On CuMatrix, it will use a CUDA-accelerated LU from CuSolver.
+  - On BandedMatrix and BlockBandedMatrix, it will use a banded LU.
 - `QRFactorization(pivot=LinearAlgebra.NoPivot(),blocksize=16)`: Julia's built in `qr`.
-  - On dense matrices this uses the current BLAS implementation of the user's computer
+  - On dense matrices, this uses the current BLAS implementation of the user's computer
     which by default is OpenBLAS but will use MKL if the user does `using MKL` in their
     system.
-  - On sparse matrices this will use SPQR from SuiteSparse
-  - On CuMatrix it will use a CUDA-accelerated QR from CuSolver.
-  - On BandedMatrix and BlockBandedMatrix it will use a banded QR.
+  - On sparse matrices, this will use SPQR from SuiteSparse
+  - On CuMatrix, it will use a CUDA-accelerated QR from CuSolver.
+  - On BandedMatrix and BlockBandedMatrix, it will use a banded QR.
 - `SVDFactorization(full=false,alg=LinearAlgebra.DivideAndConquer())`: Julia's built in `svd`.
-  - On dense matrices this uses the current BLAS implementation of the user's computer
+  - On dense matrices, this uses the current BLAS implementation of the user's computer
     which by default is OpenBLAS but will use MKL if the user does `using MKL` in their
     system.
 - `GenericFactorization(fact_alg)`: Constructs a linear solver from a generic
   factorization algorithm `fact_alg` which complies with the Base.LinearAlgebra
   factorization API. Quoting from Base:
     - If `A` is upper or lower triangular (or diagonal), no factorization of `A` is
-      required and the system is solved with either forward or backward substitution.
+      required. The system is then solved with either forward or backward substitution.
       For non-triangular square matrices, an LU factorization is used.
       For rectangular `A` the result is the minimum-norm least squares solution computed by a
       pivoted QR factorization of `A` and a rank estimate of `A` based on the R factor.
@@ -94,23 +94,22 @@ LinearSolve.jl provides a wrapper to these routines in a way where an initialize
 has a non-allocating LU factorization. In theory, this post-initialized solve should always
 be faster than the Base.LinearAlgebra version.
 
-- `FastLUFactorization` the `FastLapackInterface` version of the LU factorizaiton. Notably,
+- `FastLUFactorization` the `FastLapackInterface` version of the LU factorization. Notably,
   this version does not allow for choice of pivoting method.
 - `FastQRFactorization(pivot=NoPivot(),blocksize=32)`, the `FastLapackInterface` version of
-  the QR factorizaiton.
+  the QR factorization.
 
 ### SuiteSparse.jl
 
 By default, the SuiteSparse.jl are implemented for efficiency by caching the
-symbolic factorization. I.e. if `set_A` is used, it is expected that the new
+symbolic factorization. I.e., if `set_A` is used, it is expected that the new
 `A` has the same sparsity pattern as the previous `A`. If this algorithm is to
 be used in a context where that assumption does not hold, set `reuse_symbolic=false`.
 
 - `KLUFactorization(;reuse_symbolic=true)`: A fast sparse LU-factorization which
-  specializes on sparsity patterns with "less structure".
+  specializes on sparsity patterns with “less structure”.
 - `UMFPACKFactorization(;reuse_symbolic=true)`: A fast sparse multithreaded
-  LU-factorization which specializes on sparsity patterns that are more
-  structured.
+  LU-factorization which specializes on sparsity patterns with “more structure”.
 
 ### Pardiso.jl
 
@@ -150,7 +149,7 @@ end
 
 ### CUDA.jl
 
-Note that `CuArrays` are supported by `GenericFactorization` in the "normal" way.
+Note that `CuArrays` are supported by `GenericFactorization` in the “normal” way.
 The following are non-standard GPU factorization routines.
 
 !!! note

docs/src/tutorials/caching_interface.md

@@ -1,6 +1,6 @@
 # Linear Solve with Caching Interface
 
-In many cases one may want to cache information that is reused between different
+Often, one may want to cache information that is reused between different
 linear solves. For example, if one is going to perform:
 
 ```julia
@@ -52,9 +52,9 @@ sol3.u
 
 The factorization occurs on the first solve, and it stores the factorization in
 the cache. You can retrieve this cache via `sol.cache`, which is the same object
-as the `init` but updated to know not to re-solve the factorization.
+as the `init`, but updated to know not to re-solve the factorization.
 
 The advantage of course with using LinearSolve.jl in this form is that it is
 efficient while being agnostic to the linear solver. One can easily swap in
-iterative solvers, sparse solvers, etc. and it will do all of the tricks like
-caching symbolic factorizations if the sparsity pattern is unchanged.
+iterative solvers, sparse solvers, etc. and it will do all the tricks like
+caching the symbolic factorization if the sparsity pattern is unchanged.

docs/src/tutorials/linear.md

@@ -32,6 +32,6 @@ sol = solve(prob,KrylovJL_GMRES())
 sol.u
 ```
 
-Thus a package which uses LinearSolve.jl simply needs to allow the user to
+Thus, a package which uses LinearSolve.jl simply needs to allow the user to
 pass in an algorithm struct and all wrapped linear solvers are immediately
 available as tweaks to the general algorithm.