forum.alglib.net

The alglib APIs are growing in complexity, and it now routinely takes a dozen alglib calls to setup and run a problem. There are also APIs which really do the same thing two different ways. Specifically what I ran into is that I added minnlcsetnlc2() to a problem and forgot to delete the minnlcsetnlc() call that came later (for some reason I just slapped it below the minnlcsetbc() call without thinking too closely on what I was doing). Anyway, that led to a bunch of burned time debugging why my inequality constraints weren't working at all before I finally caught it. I have a feeling I might not be the only one to wind up debugging a bug like that. It might help users making similar mistakes to raise/throw when using two APIs that do the same thing like that. Of course some more advanced users might actually want to reuse the alglib object and fiddle with the boundary conditions extensively, including calling entirely different APIs entirely, so this would probably require adding some kind of "force" flag on the API or a "permissive"-vs-"enforcing" mode for the alglib object. But this would produce a more gradual experience for the user where they'd be protected from silly mistakes by default, and then get an exception that would point them to the right flag if they were looking to do something deliberately.

Hi!

Thank you for pointing it out! Yes, there is a question of growing API - both a problem and a sign that its capabilities improve. However, that particular API, one that works with nonlinear constraints, behaves as expected: is built around "modify state" semantics. You can "set" constraints using one of two ways, you can "add" constraints (in upcoming release), you can modify constraints that were already added by rewriting them with another "set" or by "adding" something. It is done on purpose, because it allows reusing the same optimizer object when the task changes.

Sergey