(in)equality constraints via StenoGraphs specification

[brandmaier]

Currently, (in)equality constraints require some manual labor and are relatively error-prone. This is from the documentation:

parind[:y3y7] # 29
parind[:y8y4] # 30
# θ[29] + θ[30] - 1 = 0.0
function eq_constraint(θ, gradient)
    if length(gradient) > 0
        gradient .= 0.0
        gradient[29] = 1.0
        gradient[30] = 1.0
    end
    return θ[29] + θ[30] - 1
end

parind[:λ₂] # 3
parind[:λ₃] # 4
# θ[3] - θ[4] - 0.1 ≤ 0
function ineq_constraint(θ, gradient)
    if length(gradient) > 0
        gradient .= 0.0
        gradient[3] = 1.0
        gradient[4] = -1.0
    end
    θ[3] - θ[4] - 0.1
end

Wouldn't it be possible to wrap up and hide this in Stenographs, such that we can just write:

λ₂< λ₃

and, internally this is mapped to such an inequality constraint which is added to the model?

[Maximilian-Stefan-Ernst]

Improving inequality constraint syntax would be great, and I currently see two options:

1. Add this to the StenoGraph: would be nicest, but also most difficult to achive - @aaronpeikert do you think it would be feasible to add this to the macro?

2. Add an easier syntax to the optimizer interface - something like a function inqeuality_constraint(model, :λ₂, :λ₃) that constructs this function and adds it to NLopt for model fitting.

[aaronpeikert]

This is certainly possible as a macro! For this I see two options:

1. we implement a @StructuralEquationModel that replaces but calls indirectly @StenoGraphs and is capable of directly producing a SEM specification. In there we can add methods for overloading >, =, etc for node types.
2. we add features in StenoGraph to generally represent graph metadata.

I am for 1. because there we can be very SEM specific.

[brandmaier]

1. we implement a @StructuralEquationModel that replaces but calls indirectly @StenoGraphs and is capable of directly producing a SEM specification. In there we can add methods for overloading >, =, etc for node types.

I think this would be fantastic and should actually become part of the JSS paper. For ease of use, I suggest to call it @SEM. The notation should cover positivity constraints (x > 0), equality constraints (x==y), and inequality constraints (x > y).