You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: paper/paper.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,7 +74,7 @@ The solvers rely heavily on iterative linear algebra methods from `Krylov.jl` [@
74
74
Julia's JIT compiler is attractive for the design of efficient scientific computing software, and, in particular, mathematical optimization [@lubin2015computing], and has become a natural choice for developing new solvers.
75
75
76
76
While several options exist to solve \eqref{eq:nlp} in Julia, many rely on wrappers to solvers implemented in low-level compiled languages.
77
-
For example, if \eqref{eq:nlp} is modeled using JuMP [@jump], it can be passed to solvers like IPOPT [@wachter2006implementation] or Artelys Knitro [@byrd2006k] via Julia’s native C++ and Fortran interoperability.
77
+
For example, if \eqref{eq:nlp} is modeled using JuMP [@jump], it can be passed to solvers like IPOPT [@wachter2006implementation] or Artelys Knitro [@byrd2006k] via Julia’s native C and Fortran interoperability.
78
78
However, these interfaces often lack flexibility with respect to data types and numerical precision.
79
79
In contrast, solvers written in pure Julia can operate seamlessly with a variety of arithmetic types or even GPU array types.
80
80
This capability is increasingly important as extended-precision arithmetic becomes more accessible through packages such as GNU MPFR, shipped with Julia.
0 commit comments