`Utilities.value_type` can be incorrect for `ScalarNonlinearFunction`

[klamike]

I have no idea how you'd fix this besides removing value_type(T, ::Type{ScalarNonlinearFunction}), but currently it is misleading since it just returns T:

using MathOptInterface

# make a nonlinear function with a Float64 in it
model = MathOptInterface.Utilities.Model{Float64}()
x = MathOptInterface.add_variable(model)
expr = convert(MathOptInterface.ScalarNonlinearFunction, MathOptInterface.VariableIndex(1) + 2.0)

# ask jump what the type will be if we eval with Float32
VT = MathOptInterface.Utilities.value_type(Float32, typeof(expr))
# Float32

# check the real type
RT = typeof(MathOptInterface.Utilities.eval_variables(x -> 3.0f0, model, expr))
# Float64

@assert VT === RT 
# AssertionError: VT === RT

It would be nice to have a function that converts all the constants in a nonlinear function to a given type

[odow]

We don't really support nonlinear for anything other than Float64. I'm not sure what the right fix is.

[odow]

What context did this come up in?

[klamike]

Updating the MOI wrapper for ExaModels, I wanted to automatically be able to figure out what the float type of a MOI model is so I could pass the correct T to ExaCore(T) (like a MOI version of JuMP.value_type(typeof(model))). So I went looking into MOIU to see if there is a utility for that, and I came across Utilities.value_type which sounds like it could be what I want, given the similarity to JuMP.value_type. Then I saw the definition for ScalarNonlinearFunction and realized it's wrong with the current eval code.

I ended up deciding to just require that users pass it in manually if they are using MOI with a float type other than Float64. Which isn't ideal, but coming from JuMP the wrapper can look at the T in GenericModel{T} so at least there it's not a problem.

[odow]

I ended up deciding to just require that users pass it in manually if they are using MOI with a float type other than Float64.

Yes, this is the recommended way.

We don't really have the concept of a number type for MOI models in the same way that JuMP does.

[odow]

I think I'm going to close this as won't fix. It's an edge-case, and I don't know if there is a better definition. Returning Float64 is wrong for functions like ScalarNonlinearFunction(:log, Any[x]). The underlying issue is that you had a mix of number types in the SNF. That's something we considered without coming to a firm conclusion, so we punted for now.

It is expected that MOI has a more cumbersome API than JuMP, including need to pass parameters that you might expect could be inferred from the model. That's one argument to have a higher-level layer like JuMP/Convex/ExaModels etc to hide that complexity.