-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
No problems to change the keywords so as to avoid confusion. However
My prefererence is for the Prop. 2, it is 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 |
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 |
... or just 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, |
@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? |
Hi @emmt , Sorry for this late reply. I would suggest something like 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 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: Thanks. |
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 We could add a The non-linear equality constraints could be added later to the Julia interface. |
Thank you for the explanation. The names you choose in 4f4c8df look very reasonable to me.
I agree that the suffix is not really needed in this particular situation.
Great! Thanks. |
Hi @emmt ,
What about
eqconstr
--->leqconstr
,ineqconstr
--->lineqconstr
?The current version may confuse some users.
Thanks.
Zaikun
The text was updated successfully, but these errors were encountered: