Sungho Shin

@dpo Thanks for the comment! Of course one can always write a parser that converts a sparse NLPModel into a dense NLPModel. But we're particularly interested in models that are...

@dpo Indeed `jac_coord!` is sufficient if we're always working with `ADNLPModels`. But solvers, which should work with any eligible `NLPModel` given by the user, cannot assume that NLPModel given by...

> If you know your problem is dense and you know your solver will exploit that, there's no need to call (or even implement) The issue is that the solver...

@abelsiqueira yes, that part I agree. But this assumes that we have full control of modeling side and solver side. I'm talking about the situation where the solver cannot expect...

No worries. We completely understand your trying to make NLPModels minimal, and that is the reason why we like NLPModels.jl 😉 We'll discuss this further internally and think about other...

Thanks for reporting this @IlyaOrson, we'll try to look into it. `MadNLPHSL` build on Windows has not been tested before, and it might have some issues. Alternatively, you can compile...

@IlyaOrson unfortunately no, we cannot redistribute HSL due to license issues. But indeed BinaryProvider seems to be dead. I'll keep this open and look into alternatives

yes, @baggepinnen `ips.x` is the original primal variable + slack variables, which we treat as MadNLP's internal variable. We'll look into whether there could be less confusing naming for this...

Can't this be achieved with the current `solve!` function (of course, after your PR #215 is merged 😅)?

ah, I see your point. Currently, in MadNLP we don't support updating `ips.xl` and `ips.xu` (the upper and lower bounds), and only support updating `ips.x`, `ips.y`, `ips.zl`, `ips.zu`. Indeed adding...