Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eqconstr and ineqconstr #3

Closed
zaikunzhang opened this issue Sep 22, 2023 · 7 comments
Closed

eqconstr and ineqconstr #3

zaikunzhang opened this issue Sep 22, 2023 · 7 comments

Comments

@zaikunzhang
Copy link
Member

Hi @emmt ,

What about

eqconstr ---> leqconstr,

ineqconstr ---> lineqconstr ?

The current version may confuse some users.

Thanks.

Zaikun

@zaikunzhang zaikunzhang changed the title eqconstr and ineqconstr, eqconstr and ineqconstr Sep 24, 2023
@emmt
Copy link
Collaborator

emmt commented Sep 25, 2023

No problems to change the keywords so as to avoid confusion. However lineqconstr sounds like an abbreviation of linear equality constraints which may be as much confusing. I have added some alternatives below:

Proposition Linear equality contsraints Linear inequality constraints
0 eqconstr ineqconstr
1 leqconstr lineqconstr
2 lc_eq lc_ineq
3 linconstr_eq linconstr_ineq

My prefererence is for the Prop. 2, it is short, lc is understandable abbreviation (I believe) for linear constraints, the differences between the two stand out clearly so there should be no confusion, yet the keywords remain short.

Another lack of clarity when reading the call to an optimizer with linear inequality constraints is the comparison direction which is not clear (is it A⋅x ≤ b or A⋅x ≥ b?). We can find a more readable way to indicate constraints. Like (A, ==, b) for linear equality contraints, and (A, ≤, b) or (A, ≥, b) for linear inequality contraints. But this seems a bit odd and may wrongly suggest that (A, <, b) or (A, >, b) are also possible. Perhaps I am digressing...

@emmt
Copy link
Collaborator

emmt commented Sep 25, 2023

BTW If the non-linear constraints are provided by a separate function (for COBYLA), we also have to find a keyword for that. Following Prop. 2 yields nlc_ineq.

@emmt
Copy link
Collaborator

emmt commented Sep 26, 2023

BTW If the non-linear constraints are provided by a separate function (for COBYLA), we also have to find a keyword for that. Following Prop. 2 yields nlc_ineq.

... or just nlc?

If the non-linear constraints are provided by another function, then means to specifiy the number of constraints are needed. A first possiblity is to initially call the non-linear constraints function to count the number of elements in the result but that costs a call to this function. The other possibility is to specify the non-linear constraints as a 2-tuple, say, (m,c) with m the number of constraints and c the function implementing these constraints. In fact it is easy to distinguish the 2 cases from the called function, so I may simply implement the 2 possibilities.

@emmt
Copy link
Collaborator

emmt commented Sep 26, 2023

@zaikunzhang The Julia interface to the 5 algorithms of your PRIMA libary is now complete, with all functions documented and tested. The only remaining points are the name of the keywords for the linear and non-linear constraints and the high level interface. I would like to converge on the former so that I can release a 1st version in order to use these methods in other packages (e.g. in OptimPack) before considering drafting the high level interface. Do you have any thoughs about the proposed keywords?

@zaikunzhang
Copy link
Member Author

Hi @emmt ,

Sorry for this late reply.

I would suggest something like linear_equality_constaint, linear_inequality_constaint, nonlinear_equality_constraint``, and nonlinear_inequality_constaint`.

I do not know how keywords work in Julia. Do the users need to spell these names always? If so, maybe you would prefer shorter names, such as linear_ceq, linear_cineq, nonliear_ceq, and nonlinear_cineq (or switch the words before and after the underscore).

As long as the names are user-friendly and conform to Julia conventions and common (best) practices, they are good names.

BTW, I do think the high-level Julia interface should accept nonlinear equality constraints as well, not only nonlinear inequalities. The Fortran code only accepts the latter due to the design of the algorithm. Due to limitations of the language, I did not choose to accept nonlinear equalities and then wrap them as inequalities in the Fortran API, but it should be done in the high-level interfaces. Here is the implementation in MATLAB:

https://github.com/libprima/prima/blob/aab38e1668ae59e16fc668990d4522e32d4ae5bc/matlab/interfaces/cobyla.m#L512-L539

Thanks.

@emmt
Copy link
Collaborator

emmt commented Oct 17, 2023

There are no real Julia conventions except to use lower case letters and avoid underscores unless the name is too hard to read. A reason to use keywords instead of positional arguments (apart from that fact the keywords ussually have default values) is to make clear the purpose of the argument. For our needs, I would use abbreviations to avoid too long keyword and underscores to facilitate reading and avoid confusion. I agree that prefixes lc_ and nlc_ for "(non)linear constraints" are quite cryptic. I think that something like linear_eq, nonlinear_ineq, etc. would be quite readable and understandable. I have done this in commit 4f4c8df.

We could add a _constr suffix but it would convey no additional information (all these keywords are for constraints and what really matter is to known the type of the constraints).

The non-linear equality constraints could be added later to the Julia interface.

@zaikunzhang
Copy link
Member Author

zaikunzhang commented Oct 17, 2023

There are no real Julia conventions except to use lower case letters and avoid underscores unless the name is too hard to read. A reason to use keywords instead of positional arguments (apart from that fact the keywords ussually have default values) is to make clear the purpose of the argument. For our needs, I would use abbreviations to avoid too long keyword and underscores to facilitate reading and avoid confusion. I agree that prefixes lc_ and nlc_ for "(non)linear constraints" are quite cryptic. I think that something like linear_eq, nonlinear_ineq, etc. would be quite readable and understandable. I have done this in commit 4f4c8df.

Thank you for the explanation. The names you choose in 4f4c8df look very reasonable to me.

We could add a _constr suffix but it would convey no additional information (all these keywords are for constraints and what really matter is to known the type of the constraints).

I agree that the suffix is not really needed in this particular situation.

The non-linear equality constraints could be added later to the Julia interface.

Great!

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants