Specialized interface

[dpo]

There's stuff I must have missed in the specialized interface that perplexes me:

There seems to be a ! version of every function. But I can't make sense of some of them. Normally, ! is used when it modifies (one of) its input arguments in place. The convention is also that that argument be returned by the function. (I hear the convention is also that the modified argument should appear first.) When several arguments are modified, I'm not sure what should be done, but in our case, I'm happy with what you've done.

Here are a few cases that confuse me:

1. The following functions don't modify their input arguments. I don't see a need for them.
   • udimen!(input::Int, libname),
   • udimsh!(libname),
   • udimse!(libname)
     *
2. The following functions take a CUTEstModel as input.
   • udimen(nlp::CUTEstModel, input::Int) and udimen!(nlp::CUTEstModel, input::Int)
   • udimsh(nlp::CUTEstModel) and udimsh!(nlp::CUTEstModel)
   • etc.
   • and the same for the constrained functions.

A lot of what those functions do has already happened in the constructor, when the NLPModelMeta field was filled out. If anything is missing (e.g., the variable names), then I think it should go into the constructor. It's ok to add fields to NLPModelMeta if any are missing.

Exceptions are ureport/creport and ustats/cstats, but I wonder if the counting should take place in objgrad, cons, etc. I'm not sure yet what the appropriate interface should be, though. I'm not sure.

I hadn't realized some of the functions in there take a CUTEstModel as input. It feels strange, but I guess it could be useful if you want to be more surgical.

Question: What do we do with the sparse matrices in finite-element format? Is there a package out there that could help us with them?

[abelsiqueira]

Yes, these functions shouldn't have been created, I should have checked for the need of inplace.
I will try modify the script to get this automatically if I can. Essentially, if the output variables aren't arrays, then it shouldn't have to be an inplace version of it.
The second case I will have to think more carefully.

About the finite element format, I don't know much about it so I left it alone.

And about the convention, I wasn't aware of it, but I don't like it (at least in this case) because using the CUTEst order is more natural for people coming from other languages. I'm glad you're satisfied with what we got.

[abelsiqueira]

I'm finalizing this fix. I'm not using nlp as argument for the functions on CUTEstModel and cutest_finalize. Also removing

• *dimse, that might be used when we find something for finite-element format;
• *names, which we could implement to optionally be used in CUTEstModel;
• *vartype, for the same reason as above.

The inplace problem was also fixed, I believe.

[abelsiqueira]

Fixed by #41