Using single precision tolerances will disable the stopping criterion in the Fortran interface

[gabrielgggg]

Not so much an issue as a gotcha. Suppose I have:

CALL nlo_set_xtol_rel(ires, opt, 1.0E-4)

Then the algoritm (I was using for example NLOPT_GN_CRS2_LM) will not stop unless it hits the maxeval bound, or it will go on forever if no bound on number of evaluation was set.

With a 1.0D-4 tolerance, the code works as expected. The difference is that 1.0E-4 is single precision and 1.0D-4 is double.

Edit: this is with ifort (IFORT) 2021.3.0 20210609

[awvwgk]

This issue is mainly caused due to the usage of implicit interfaces in the Fortran API, by declaring the interface explicitly this would be caught at compile time.

implicit none(type, external)
integer, parameter :: il = selected_int_kind(18)
integer, parameter :: dp = selected_real_kind(15)
interface
  ! ...
  subroutine nlo_set_xtol_rel(ires, opt, xtol)
    import :: il, dp
    implicit_none
    integer, intent(out) :: ires
    integer(il), intent(in) :: opt
    real(dp), intent(in) :: xtol
  end subroutine nlo_set_xtol_rel
  ! ...
end interface
integer :: ires
integer(il) :: opt
! ...
call nlo_set_xtol_rel(ires, opt, 1.0e-4)
! ...
end

Trying to compile this example with ifort yields a compile time error and avoids passing a 32 bit floating point number when a 64 bit float is expected:

❯ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.2.0 Build 20210228_000000
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.

❯ ifort mwe.f90
mwe.f90(18): error #6633: The type of the actual argument differs from the type of the dummy argument.   [1.0E-4]
call nlo_set_xtol_rel(ires, opt, 1.0e-4)
---------------------------------^
compilation aborted for mwe.f90 (code 1)

Maybe the nlopt.f include file for Fortran could provide such interfaces blocks to make the API type-safe for Fortran users?