BigFloat in HomotopyContinuation.jl

[lkastner]

HomotopyContinuation.jl does not deal well with Julia's BigFloat type, see
JuliaHomotopyContinuation/HomotopyContinuation.jl#528

Unfortunately these can occur in the poly_to_expr method. It might be worthwhile to change the line

+([*([Rational(c), [v[i]^e for (i,e) in enumerate(a)]...]...) for (c,a) in poly ]...)

to

+([*([convert(Float64, Rational(c)), [v[i]^e for (i,e) in enumerate(a)]...]...) for (c,a) in poly ]...)

to work around this problem here. What do you think?

[taboege]

Oh, interesting. Can you help me understand how and where exactly BigFloat appears here?

One assumption I made is that poly_to_expr would be invoked with an element of a polynomial ring over QQ (as opposed to a finite field or number field or function field or whatever else there is). This is legitimate, right? (Would you recommend that I also add a type constraint to the paramter f while we're at it?) And from OSCAR we will always get QQ coefficients which convert cleanly to Rational, right?

Do I then understand correctly that HomotopyContinuation.jl takes these Expressions which are created with exact rational coefficients and does a conversion to Float64 or BigFloat (depending on what?) and this creates trouble down the line. The recommendation is to make coefficients Float64 and there is really no other sensible choice?

If yes, then your proposed change seems only logical.

[lkastner]

So the polynomial I am working with is

{a1: 0.995469}*y^7 + {a1: -3.27772}*y^6 + {a1: 11.9146}*y^5 + {a1: -35.0479}*y^4 + {a1: 36.7966}*y^3 + {a1: -83.6948}*y^2 + {a1: 7.52674}*y + {a1: -0.172566}

over algebraic_closure(QQ). This is an incomplete presentation, sorry. I also attach it here, it can be loaded with Oscar.

floc.json

After poly_to_expr we arrive at:

-3769339880374219037698931643259717253643930984982191194730355195293517572/21842904164512567744056017184579521625787281463911286506485610980712278125 + (6118466153938242389334943463355398754000601327915171820553011268/812897336059063824123390256837678480378708534760820806464791875)*y + (-4570216939780813810379417073507734074629363534347063709004/54605731159235564557425127924046294605683631853981875625)*y^2 + (7103861117094068024876962140300922298566579208504/193057710667275780745793421172913335295563585625)*y^3 + (-23922056151292667587087859392829982629087/682552524375196666166172020601823855625)*y^4 + (143758397523242766169393169096997/12065769010745915087468114228125)*y^5 + (-15683431350857652/4784859481306375)*y^6 + (319962851/321419125)*y^7

Now take e.g. the first coefficient:

julia> typeof(-3769339880374219037698931643259717253643930984982191194730355195293517572/21842904164512567744056017184579521625787281463911286506485610980712278125)
BigFloat

This then makes HomotopyContinuation.jl choke:

ERROR: LoadError: MethodError: no method matching HomotopyContinuation.ToricHomotopy(::MixedSystem{(0x3a2fe7b079ccc209, 1)}, ::Vector{Vector{Complex{BigFloat}}})
The type `HomotopyContinuation.ToricHomotopy` exists, but no method is defined for this combination of argument types when trying to construct it.

Nevertheless for various reasons we already have a conversion to Float64 built in for several fields. So now my suggestion would be to go directly and just do

+([*([Float64(c), [v[i]^e for (i,e) in enumerate(a)]...]...) for (c,a) in poly ]...)

instead of my previous suggestion. convert will not work for some of these fields, since we wanted the user to be aware of the conversion. There should be no loss compared to the previous version though, as HomotopyContinuation.jl converts to Float64 anyway.

I will prepare a PR to this repo though in context of oscar-system/Oscar.jl#5629 , as one can use OscarHomotopyContinuation.jl as backend for visualization for coefficient fields that don't have fast solvers otherwise.