How to pass libname to the raw interface

[juliasmoothoptimizers]

How to pass libname to the raw interface

[dpo]

@abelsiqueira Good point. I'm thinking the expert interface isn't meant to be used with objects of type CUTEstModel. So an expert user will probably want to do something like this instead:

sifdecoder("ROSENBR", expert=true);  # this creates a shared lib with a fixed name, e.g., libCUTEstJL
(nvar, ncon) = cutest_cdimen()
(x, bl, bu, v, cl, cu, equatn, linear) = cutest_csetup(e_order, l_order, v_order)
nnzh = cutest_cdimsh()
nnzj = cutest_cdimsj()
etc.

or perhaps

(x, bl, bu, v, cl, cu, equatn, linear, nnzh, nnzj) = cutest_setup(e_order, l_order, v_order)

which would call csetup and then close the open file.

I like keeping problem-dependent library names in the convenient interface because I'm hoping we'll find a way to have several problems open at once. So in sifdecoder(), we have expert=false by default.

What do you think?

[abelsiqueira]

The expert=true flag looks like a good solution, but I don't like the calling the csetup (that is an expert cutest function) without the exact cutest arguments.
The drawback of not fixing the name is that we cannot mix the codes. If we could mix the codes, we could reduce the number of ccalls in the other functions to make the code cleaner, and also use the CUTEstModel to receive these basic informations while being able to also use the raw functions.

An alternative to consider: using __init__ to create a const libname with a randomized name such as libCUTEstJLA38FB2.so. This looks possible and feasible. What do you think?

[dpo]

Do you mean that you want to retain the exact Fortran calling sequence and write

cutest_csetup(status, input, iout, io_buffer, n, m, x, xl, xu, y, cl, cu, equatn, linear, e_order, l_order, v_order)

directly? There's little difference between that and a direct ccall. I've no specific objection, but maybe we could at least use the fact that Julia allows us to distinguish between input and output arguments?!

How about the expert calls all accept one optional parameter (the library name), which is some prespecified name by default (e.g., libCUTEstJL), but could be specified by the user so the two interfaces could be used together? Something like:

cutest_cdimsh(status, nnzh, libname="libWhatever")

or

nnzh = cutest_cdimsh(libname="libWhatever")

So

sifdecoder("ROSENBR", expert=true)  # builds libCUTEstJL.so
cutest_cdimsh(status, nnzh)

"just works", but

nlp = CUTEstModel("ROSENBR")
cutest_cdimsh(status, nnzh, libname=nlp.libname)

also works.

[abelsiqueira]

My first idea was simply that, to avoid calling ccall, because ccall implies knowledge of the library name, and inclusion of the pointer for everything. This interface can be easily created by a script from the contents of $CUTEST/include/cutest.h, which is what I do.
We could make then, a third interface, that follows the cutest naming convention and parameter usage, but returns the output variables in a tuple. However, this goes back to a question I posted on the previous CUTEst.jl interface: is there a target audience for this?
Also, this interface is not so easily generated by script, and I want to avoid doing it by hand. I'll try to read this information from the man pages of actual codes.

Your suggestion seems to work. I'll implement that.

[dpo]

I understand. I'm happy to also include a "bare bones", "close to the metal" interface that imitates the Fortran calls. I suppose an advantage might be that a Fortran code could be essentially copy-pasted and turned into a Julia code.

Thanks!

[abelsiqueira]

The interface is up, with a test (btw, the travis is still with problems, but I'm working on it).
It is very low-level, in the meaning that the types need to be pointers.
test/test_raw.jl is the test.

[abelsiqueira]

The intermediate interface is also up and tested (cfn and cofg). It did take a lot of time, but the job is automated.
Now there are two interfaces: (1)CUTEst.xxx which is the same as the ccall, but without the ccall needs. e.g.

CUTEst.cfn(st, nvar, ncon, x, f, c)

Where st, nvar and ncon are Ptr{Int32}, and x, f and c are Ptr{Float64}. Optionally, we can pass the library in the end; and (2)CUTEst.jl_xxx with specific input and output, and no need to pass pointers. e.g.

(f,c) = CUTEst.jl_cfn(nvar, ncon, x)

Where nvar and ncon are integers, x is an array of Float64, f is a Float64 and c is an array of Float64. We can also pass a library optionally.

[dpo]

That's amazing. Thanks a lot for your work!

I took a quick look and I have two questions:

1. Perhaps we should use Cint[0] instead of [Int32(0)] everywhere since there's a guarantee that Cint always corresponds to a C integer?!
2. the medium and expert interfaces don't specify any types. Wouldn't we avoid a lot of trouble if we imposed the types of the input and output arguments there? It might not be easy to automate.

[abelsiqueira]

1. Will do. And Cdouble too.
2. That's the next step. I will start this today.

[abelsiqueira]

Implemented. Changed almost everywhere to Cint and Cdouble. This includes CUTEst.jl.
In the intermediate package, however, I tried to be a little lenient. The integer type is Integer, so it should accept Int32 as we are creating, and Int64 as is default in NLP. The boolean type in Bool, and the floating point type must be Float64 because we are inputing Array{Float64, 1} sometimes, so an abstract type to float does not work.