OK I can help you from the Octave end. With most Octave m-files of this nature, the m-file does the input validation and then calls a compiled function that does the heavy lifting.
Taking linprog as an example, you can see this line towards the end of the function:
[x(1:nr_f, 1) fval(1, 1)] = glpk (f, [A; Aeq], [b; beq], lb, ub, ctype);
Everything before that line was input validation.
In principle, (and yes we need to verify that with reality), that single line can be replaced by a call to HiGHS using HiGHS’s preferred function format and that would be a change in the solver that is invisible to the end user. In practice there will be some diagnostics that will reveal what solver is being used.
Of course, if the preceding input validation doesn’t make sense for HiGHS, it would be better to write a separate m-file that calls HiGHS.
Can you provide the preferred function prototype for the HiGHS function to do linear programming? I can help with the m-file end.
Edit: to explain that line of code, it is calling a function called glpk and passing it all the constraint matrices and RHS values and all that good stuff. The glpk function is in this case another m-file (but it could have been compiled too if the linprog developer wanted) that does yet more input validation and then calls this compiled function:
[xopt, fmin, errnum, extra] = ...
__glpk__ (c, A, b, lb, ub, ctype, vartype, sense, param);
__glpk__ function in turn is a compiled function that simply calls the GLPK API and returns the results. The linprog developer could have called
__glpk__ directly if they didn’t need the second round of input validation that glpk.m was providing.
Similarly, let’s say we have a C++ function named
__highs__ that calls the HiGHS API. That function
__highs__ can be called by an m-file named say highs.m. In future, linprog.m can switch over to calling highs.m or even
__highs__ instead of calling glpk.m like it is now.
Next steps for you: create a C++ function called
__highs__ and make it call the HiGHS API.
@siko1056, do you think this should be a DLD oct file like glpk or is there a better approach? Will this be an external package like optim or will it be a DLD in core like glpk and Qhull functions?
Edit 2: @jajhall if you want to see an example of a C++ function that calls a private library API, there are several examples in octave: 439eb9bd4c04 /libinterp/dldfcn/ but see the smaller ones first before you see
__glpk__.cc. Also, don’t worry about the stuff like Octave namespaces yet. If you write a C++ function to call the HiGHS API we can build from there.