Code Monkey home page Code Monkey logo

Comments (5)

jschueller avatar jschueller commented on June 1, 2024 1

I modified the Python interface to return nan on exception
in the C layer, maybe we could mention it in prima.h

from prima.

zaikunzhang avatar zaikunzhang commented on June 1, 2024

Hi @jschueller Julien,

Thank you for raising this extremely important point.

I fully agree that function evaluation failures should be handled properly. This is vital for the robustness and reliablity of the solvers.

Indeed, this point has been mentioned in the previous discussions with you about how to test PRIMA and its interfaces / translations to other languages. Maybe that point did not catch your attention since we had many things to discuss. See "2. TOUGH tests" of "What kind of tests are sufficient for the porting or translation of PRIMA?" (BTW, I highly recommend you to read all the "discussions" I wrote on PRIMA and also write down your thoughts as discussions, so that we can understand each other better, and future contributors will understand us better).

The "TOUGH test" is a test on problems where function evaluations fail or return exceptional values randomly. See slide 23 of my talk at ICIAM 2023 for details. The following MATLAB code implements a generator of such problems:

https://github.com/libprima/prima/blob/main/matlab/tests/private/tough.m

The handling of function evaluation failures (and exceptional function values) has been implemented in the MATLAB interface:

https://github.com/libprima/prima/blob/main/matlab/interfaces/private/evalobj.m
https://github.com/libprima/prima/blob/main/matlab/interfaces/private/evalcon.m

The idea is to

  1. catch the failure (and raise a warning) if it occurs, and then take NaN as the function value.
  2. after 1 is done, apply a moderated extreme barrier to handle the exceptional values, basically NaN and Inf (see Sec. 4.5 and 5.2 of my paper with Tom @ragonneau on Powell's methods).

The Fortran implementation, however, only handles exceptional function values but not evaluation failures, as Fortran does not handle exceptions well (no try ... catch ...):

https://github.com/libprima/prima/blob/main/fortran/common/evaluate.f90

I will not implement handling of evaluation failures in the Fortran implementation unless there exists a simple and straightforward implementation. This is due to the limitation of the language --- its incapability of handling exceptions (it should be handled by the caller, which might be an interface to another language, e.g., MATLAB, Python, C, ...).

Meanwhile, in the interface / translation of PRIMA to any language with a built-in mechanism of handling exceptions, evaluation failures and exceptional function values must be handled in a way similar to the MATLAB interface. In addition, the interface / translation should eventually implement and pass the TOUGH test, as the MATLAB interface has achieved. I insist this (indeed, I enforce this on all solvers I develop, see, e.g., blockwise-direct-search/bds#6). Without passing the TOUGH test, the interface / translation is not complete.

Thanks.

from prima.

jschueller avatar jschueller commented on June 1, 2024

ok, so objective function errors results in f=funcmax, some penalizing value

but the nan value can be used a a simple mean to indicate failure

so I think it should be done in the Fortran layer; we can check for nan there and set funcmax

that way it will benefit all the interfaces as well (and not duplicate that logic)

from prima.

zaikunzhang avatar zaikunzhang commented on June 1, 2024

ok, so objective function errors results in f=funcmax, some penalizing value
but as you mentionned the nan value (or some bool) can be used a a simple mean to indicate failure
so I think it should be done in the Fortran layer (we can check for nan there and set funcmax)
that way it will benefit all the interfaces as well (and not duplicate that logic)

Yes, this Fortran layer does it:
https://github.com/libprima/prima/blob/main/fortran/common/evaluate.f90#L62-L64

However, I do believe the same should still be done in the evalobj / evalcon of the interfaces (MATLAB, Python, C ...). Why? Think about the future native implementation in these languages ---- such an implementation will likely share the evalobj / evalcon with the interfaces. At that time, we cannot rely on what is done in the Fortran implementation anymore.

from prima.

jschueller avatar jschueller commented on June 1, 2024

oh, then there is nothing to do in the fortran layer

from prima.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.