Merge pull request #783 from prbzrg/to-arbnumerics

Replace `ArbFloats` by `ArbNumerics`

Author: ChrisRackauckas

docs/src/basics/faq.md

@@ -12,9 +12,9 @@ For guidelines on debugging ODE solve issues, see
 First of all, don't panic. You may have experienced one of the following warnings:
 
 > dt <= dtmin. Aborting. There is either an error in your model specification or the true solution is unstable.
-> 
+>
 > NaN dt detected. Likely a NaN value in the state, parameters, or derivative value caused this outcome.
-> 
+>
 > Instability detected. Aborting
 
 These are all pointing to a similar behavior: for some reason or another, the
@@ -185,7 +185,7 @@ numerically and thus results in much better performance. This is seen in many in
 SciMLBenchmarks. Thus it is recommended that in almost all or most situations, one should use the
 mass matrix form of the DAE solver.
 
-However, it is generally recommended that if you are solving a DAE that you use 
+However, it is generally recommended that if you are solving a DAE that you use
 [ModelingToolkit.jl](https://mtk.sciml.ai/dev/) because it has many utilities for pre-processing
 DAEs to make them more numerically stable. For example, if your algebraic conditions are not
 uniquely matching to algebraic variables (i.e. you have at least one unique algebraic variable
@@ -455,7 +455,7 @@ thing you can do is use
 
 You can't. For floating-point numbers, you shouldn't use below `abstol=1e-14`
 and `reltol=1e-14`. If you need lower than that, use arbitrary precision numbers
-like BigFloats or [ArbFloats.jl](https://github.com/JuliaArbTypes/ArbFloats.jl).
+like BigFloats or [ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl).
 
 ## Autodifferentiation and Dual Numbers
 

docs/src/basics/overview.md

@@ -31,7 +31,7 @@ timespan and `BigFloat` for specifying the initial condition, then the solution
 will solve using `Rational{BigInt}` for the timesteps and `BigFloat` for the
 independent variables. A wide variety of number types are compatible with the
 solvers such as complex numbers, unitful numbers (via Unitful.jl),
-decimals (via DecFP), dual numbers, and many more which may not have been tested
+decimals (via [DecFP](https://github.com/JuliaMath/DecFP.jl)), dual numbers, and many more which may not have been tested
 yet (thanks to the power of multiple dispatch!). For information on type-compatibility,
 please see the solver pages for the specific problems.
 

docs/src/features/callback_functions.md

@@ -522,7 +522,7 @@ However, at some point we will hit machine epsilon, the value where
 `t + eps(t) == t`, so we cannot measure infinitely many bounces and instead will
 be limited by the floating-point accuracy of our number representation. Using
 alternative number types like
-[ArbFloats.jl](https://github.com/JuliaArbTypes/ArbFloats.jl) can allow for this
+[ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl) can allow for this
 to be done at very high accuracy, but still not infinite. Thus, what we need to
 do is determine a tolerance after which we assume the accumulation has been
 reached and define the exit behavior. In this case, we will say when the

docs/src/index.md

@@ -42,7 +42,7 @@ DifferentialEquations.jl integrates with the Julia package sphere with:
   - Automatic plotting of time series and phase plots
   - Built-in interpolations
   - Wraps for common C/Fortran methods like Sundials and Hairer's radau
-  - Arbitrary precision with BigFloats and Arbfloats
+  - Arbitrary precision with BigFloats and [ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl)
   - Arbitrary array types, allowing the definition of differential equations on
     matrices and distributed arrays
   - Unit checked arithmetic with Unitful
@@ -67,7 +67,7 @@ Additionally, DifferentialEquations.jl comes with built-in analysis features, in
     for guidance on PRs, issues, and other matters relating to contributing to SciML.
   - See the [SciML Style Guide](https://github.com/SciML/SciMLStyle) for common coding practices and other style decisions.
   - There are a few community forums:
-    
+
       + The #diffeq-bridged and #sciml-bridged channels in the
         [Julia Slack](https://julialang.org/slack/)
       + The #diffeq-bridged and #sciml-bridged channels in the

docs/src/solvers/ode_solve.md

@@ -71,7 +71,7 @@ At medium tolerances (`>1e-8`?) it is recommended you use `Rodas5P`,
 `Rodas4P` (the former is more efficient, but the latter is more reliable),
 `Kvaerno5`, or `KenCarp4`. As native DifferentialEquations.jl solvers,
 many Julia numeric types (such as BigFloats,
-[ArbFloats](https://github.com/JuliaArbTypes/ArbFloats.jl), or
+[ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl), or
 [DecFP](https://github.com/JuliaMath/DecFP.jl)) will work. When the equation is
 defined via the `@ode_def` macro, these will be the most efficient.
 
@@ -960,22 +960,22 @@ using IRKGaussLegendre
 `IRKGL16(;kwargs...)` has the following arguments:
 
   - second_order_ode (boolean):
-    
+
       + =false (default): for a ODEProblem type
       + =true: for a second-order differential equation
 
   - simd (boolean):
-    
+
       + =true: SIMD-vectorized implementation only available for Float32 or Float64 computations
       + =false (default):  generic implementation that can use with arbitrary Julia-defined number systems
   - mstep: output saved at every 'mstep' steps. Default 1.
   - initial_extrapolation: initialization method for stages.
-    
+
       + =false: simplest initialization
       + =true (default): extrapolation from the stage values of previous step
   - maxtrials: maximum number of attempts to accept adaptive step size
   - threading
-    
+
       + =false (default): sequential execution of the numerical integration
       + =true: computations using threads (shared memory multi-threading) for stage-wise parallelization