# Arbitrary/High-precision optimisation of NLP
**URL:** https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973
**Category:** Optimization (Mathematical)
**Tags:** optimization
**Created:** [November 18, 2025, 5:58pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973 "2025-11-18T17:58:47Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@arnerob](https://discourse.julialang.org/u/arnerob)
#### Post date: [November 18, 2025, 5:58pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/1 "2025-11-18T17:58:48Z")
I have solved a non-linear program with JuMP and IPopt. I want to refine the solution, but am limited by the Float64 precision.
Therefore, I tried MadNLP and ExaModels, as they say that they support `AbstarctFloat`, [see here](https://madsuite.org/MadNLP.jl/dev/tutorials/multiprecision/), which would let me use `BigFloat` and arbitrary precision. However when implementing, this gave me an error. This error stays when I use `Float128`.
The error I get is
```julia-auto
ERROR: AssertionError: is_supported(ipm_opt.linear_solver, T)
Stacktrace:
[1] MadNLPSolver(nlp::ExaModel{…}; kwargs::@Kwargs{})
@ MadNLP ~/.julia/packages/MadNLP/RwL3t/src/IPM/IPM.jl:121
[2] MadNLPSolver
@ ~/.julia/packages/MadNLP/RwL3t/src/IPM/IPM.jl:115 [inlined]
[3] madnlp(model::ExaModel{…}; kwargs::@Kwargs{})
@ MadNLP ~/.julia/packages/MadNLP/RwL3t/src/IPM/solver.jl:10
[4] madnlp(model::ExaModel{Float128, Vector{…}, Nothing, ExaModels.Objective{…}, ExaModels.Constraint{…}})
@ MadNLP ~/.julia/packages/MadNLP/RwL3t/src/IPM/solver.jl:9
[5] top-level scope
@ ~/TEST/NLPsimplified.jl:51
Some type information was truncated. Use `show(err)` to see complete types.
```
and the code is
```julia-auto
using ExaModels, MadNLP, LinearAlgebra
using Quadmath
T = Float128
function delta_optimization_model(T; tuples::Vector{Tuple{T,T}})
n = 12
x0_vals = first.(tuples[1:n])
y0_vals = last.(tuples[1:n])
core = ExaCore(T)
x = variable(core, 1:n; start=x0_vals)
y = variable(core, 1:n; start=y0_vals)
IJ = [(i, j) for i in 1:n for j in i+1:n]
constraint(core,
(x[i] - x[j])^2 + (y[i] - y[j])^2 - T(4.0) for (i, j) in IJ;
ucon=zero(T)
)
objective(core,
log((x[i] - x[j])^2 + (y[i] - y[j])^2) for (i, j) in IJ
)
return ExaModels.ExaModel(core)
end
raw_tuples =[
(0.0, 0.0),
(2.0, 0.0),
(1.9318729445411233, 0.5175586209793144),
(1.9318729445411233, -0.5175586209793144),
(0.199822139399187, -0.4824413832242706),
(0.199822139399187, 0.4824413832242706),
(1.6139775239283088, 0.9318303545995787),
(1.6139775239283088, -0.9318303545995787),
(0.6139775198744277, -0.8002204506287891),
(0.6139775198744277, 0.8002204506287891),
(1.0962599551249452, 1.0),
(1.0962599551249452, -1.0)
]
# T = BigFloat
# setprecision(T, 665)
nlp = delta_optimization_model(T; tuples=[Float128.(y) for y in raw_tuples])
println(nlp)
results = madnlp(nlp)
println(results)
```
(line 51 is `results= madnlp(nlp)`)
_Why does this happen?_
Note that for `Float64` the solver does run, but exits because `Problem has too few degrees of freedom.` Despite there being a lot of freedom and the initial point already being feasible.
---
### Author:  [@cvanaret](https://discourse.julialang.org/u/cvanaret)
#### Post date: [November 18, 2025, 9:02pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/2 "2025-11-18T21:02:50Z")
> [@arnerob](#):
>
> Note that for `Float64` the solver does run, but exits because `Problem has too few degrees of freedom.` Despite there being a lot of freedom and the initial point already being feasible.
You probably have more constraints than variables. I can’t answer about the rest 🙂
---
### Author:  [@apozharski](https://discourse.julialang.org/u/apozharski)
#### Post date: [November 19, 2025, 8:11am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/3 "2025-11-19T08:11:05Z")
I can explain the `MadNLP` issue simply: in order to use non `Float64`/`Float32` floating point representations, the linear solver that `MadNLP` uses to solve the KKT system at each iteration needs to support the given floating point representation. In general, I know of no supported solvers (or any in general for that matter) which support BigFloat, and I believe only the latest release of the `ma27` solver in the HSL suite supports 128 bit floating point arithmetic (@amontoison will know better).
In general though, I suspect you will struggle to solve even moderately sized problems with `Float128` due to the fact that there is no consumer grade hardware which supports non-emulated 128 bit floating point arithmetic, which means every operation has to be emulated in software. As you might imagine this is quite slow, my guess would be at least 10x slower per fp operation, but I have not benchmarked this on a modern CPU
> [@cvanaret](#):
>
> You probably have more constraints than variables. I can’t answer about the rest 🙂
In particular more _equality_ constraints than variables.
---
### Author:  [@arnerob](https://discourse.julialang.org/u/arnerob)
#### Post date: [November 19, 2025, 9:25am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/4 "2025-11-19T09:25:09Z")
Thank you, both @cvanaret and @apozharski. There are indeed more inequality constraints than variables, but is this really a problem? Many problems have more inequality constraints than variables, [e.g. here](https://madsuite.org/MadNLP.jl/stable/quickstart/) . There are no equality constraints.
I know that it might be slower to solve, but I want to refine a solution I got in `Float64`, so I hope that this approximate solution might make convergence faster.
---
### Author:  [@apozharski](https://discourse.julialang.org/u/apozharski)
#### Post date: [November 19, 2025, 9:33am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/5 "2025-11-19T09:33:24Z")
> [@arnerob](#):
>
> There are no equality constraints.
I was also confused by this. However, there _are_ equality constraints. the `constraint` function does not default `lcon` and `ucon` to \pm \infty as you expect, but defaults both to zero. So right now you have n^2 equality constraints and 2n variables 🙂
As for solving using `Float128` [these lines in `HSL.jl`](https://github.com/JuliaSmoothOptimizers/HSL.jl/blob/1ad36094220d909c225df3552b764892959b7e78/src/wrappers.jl#L185-L208) suggest that you can indeed use Float128 with the newer releases of HSL solvers, so using the e.g. `linear_solver=Ma27Solver` option in `MadNLP` would be your best bet (see this [README](https://github.com/MadNLP/MadNLP.jl/tree/master/lib/MadNLPHSL) for use instructions).
---
### Author:  [@amontoison](https://discourse.julialang.org/u/amontoison)
#### Post date: [November 19, 2025, 11:40am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/6 "2025-11-19T11:40:02Z")
@arnerob I suggest to try MadNCL with MA27 as linear solver in `Float128`.
MadNCL can easily handle more constraints than variables.
---
### Author:  [@amontoison](https://discourse.julialang.org/u/amontoison)
#### Post date: [November 19, 2025, 11:44am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/7 "2025-11-19T11:44:47Z")
@apozharski Yes, the latest release of `libhsl` added support of `Float128` in a few linear solvers.
I don’t know any sparse solver that support `BigFloat`.
We should check the Cholesky in CliqueTrees.jl.
I think we still go large scale with `MA27` in `Float128`, it will just take more time but the accuracy of the descent direction can lead to less IPM iterations.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [November 19, 2025, 12:13pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/8 "2025-11-19T12:13:38Z")
> [@amontoison](#):
>
> I don’t know any sparse solver that support `BigFloat`.
If it’s a small enough problem that `BigFloat` is practical, can’t you just use a dense solver? LinearAlgebra.jl supports arbitrary precision in its dense LU solver etcetera.
---
### Author:  [@araujoms](https://discourse.julialang.org/u/araujoms)
#### Post date: [November 20, 2025, 1:23pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/9 "2025-11-20T13:23:38Z")
[Tulip](https://github.com/ds4dm/Tulip.jl) can handle arbitrary types, including `BigFloat`. I recommend using `Double64` (from the package `DoubleFloats`) instead of `Float128`, though, as it has about the same precision and is much faster.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [November 20, 2025, 3:14pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/10 "2025-11-20T15:14:58Z")
MultiFloats may be even faster if you don’t need to handle infinite values
---
### Author:  [@araujoms](https://discourse.julialang.org/u/araujoms)
#### Post date: [November 20, 2025, 5:25pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/11 "2025-11-20T17:25:46Z")
`Multifloats` right now is in limbo between 2.x and 3.x, which is why I don’t recommend it. `DoubleFloats` is slower but boringly stable.
---
### Author:  [@amontoison](https://discourse.julialang.org/u/amontoison)
#### Post date: [November 26, 2025, 4:49am UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/12 "2025-11-26T04:49:38Z")
I totally forgot but `LDLFactorizations.jl` can be used in MadNLP.jl / MadIPM.jl / Tulip.jl and support any precision.
---
### Author:  [@yuwenchen95](https://discourse.julialang.org/u/yuwenchen95)
#### Post date: [January 5, 2026, 4:33pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/13 "2026-01-05T16:33:45Z")
Paul @pgoulart wrote [QDLDL.jl](https://github.com/oxfordcontrol/QDLDL.jl) (single-threaded) as the backend for [Clarabel.jl](https://github.com/oxfordcontrol/Clarabel.jl/tree/main), It is a no-pivot LDL factorization with arbitrary data types for [quasidefinite](https://epubs.siam.org/doi/10.1137/0805005) system, but can also work as a Cholesky factorization solver since positive definite system is just a subclass of quasidefinite system.
---
### Author:  [@amontoison](https://discourse.julialang.org/u/amontoison)
#### Post date: [January 5, 2026, 4:59pm UTC](https://discourse.julialang.org/t/arbitrary-high-precision-optimisation-of-nlp/133973/14 "2026-01-05T16:59:15Z")
I did bencharks a very long time ago between `LDLFactorizations.jl` and `QDLDL.jl`: [here](https://raw.githubusercontent.com/JuliaSmoothOptimizers/LDLFactorizations.jl/refs/heads/main/benchmark/ldl_vs_qdldl.svg).
I remember that the performances were quite bad.
We still have all scripts in `LDLFactorizations.jl` ([LDLFactorizations.jl/benchmark at main · JuliaSmoothOptimizers/LDLFactorizations.jl · GitHub](https://github.com/JuliaSmoothOptimizers/LDLFactorizations.jl/tree/main/benchmark)).
Solving large optimization problems in high precision could be quite slow with it.