Hypatia -- JuMP

I know that JuMP does not support BigFloat; however Hypatia does. Is it possible to define a problem in JuMP, in Float64, but cause Hypatia to carry out the optimization in BigFloat? I am working on a problem, where the problem definition is adequately represented in Float64, but sometimes Hypatia has difficulty converging. I would like to try to increase the number of digits used by Hypatia to obtain a solution.

1 Like

I don’t think it’s there: Generic numeric type in JuMP · Issue #2025 · jump-dev/JuMP.jl · GitHub

1 Like

If the problem data is accurately represented in Float64, then you don’t need Generic numeric type in JuMP · Issue #2025 · jump-dev/JuMP.jl · GitHub. Hypatia could expose an option to compute in a different precision than the input data. I’d suggest requesting this feature.

1 Like

One option if you want to use JuMP to build the model is to extract the Hypatia model data before optimizing, then convert c, A, b, G, h and the cones to the numeric type you want, then use Hypatia’s native interface to optimize that model. You can get the Hypatia MOI optimizer (the object in src/mathoptinterface.jl) using Models · JuMP and then get the model field. You can make a new Hypatia Model object with the converted types and then solve as in Solving · Hypatia. The issue is you won’t be able to use JuMP to query the solutions of course.

I would suggest looking at GitHub - JuliaMath/DoubleFloats.jl: math with more good bits for some performance tips on selecting a higher precision type.

Talking to MOI/JuMP devs now - it’s seems to me to be a JuMP feature that needs to be supported rather than a Hypatia feature - Generic numeric type in JuMP · Issue #2025 · jump-dev/JuMP.jl · GitHub. Because Hypatia allows any MOI model in any real floating point type already (see our MOI tests at Hypatia.jl/runmoitests.jl at e3672d2f1ad1fc1418a4a81e5fe12df26e4ff1e2 · chriscoey/Hypatia.jl · GitHub).

Thank you for all the answers, especially from Chris. I will try this work around.

1 Like