From 0b09d4c26752c319c81a17b485ce78688dac2b2d Mon Sep 17 00:00:00 2001 From: tmigot Date: Wed, 17 Dec 2025 12:13:37 -0500 Subject: [PATCH] Fix sentence on interoperability --- paper/paper.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/paper/paper.md b/paper/paper.md index 09988d1c..d9ab6275 100644 --- a/paper/paper.md +++ b/paper/paper.md @@ -74,7 +74,7 @@ The solvers rely heavily on iterative linear algebra methods from `Krylov.jl` [@ 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. While several options exist to solve \eqref{eq:nlp} in Julia, many rely on wrappers to solvers implemented in low-level compiled languages. -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. +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. However, these interfaces often lack flexibility with respect to data types and numerical precision. In contrast, solvers written in pure Julia can operate seamlessly with a variety of arithmetic types or even GPU array types. This capability is increasingly important as extended-precision arithmetic becomes more accessible through packages such as GNU MPFR, shipped with Julia.