Fix implementation of fonesca fleming problem function f1 and f2 type usage and negative signs.

[coatless]

Fixes the type issues that came up during a CRAN check submission on Solaris.

In file included from ../inst/include/ensmallen_bits/problems/problems.hpp:20:0,
from ../inst/include/ensmallen.hpp:77,
from ../inst/include/RcppEnsmallen.h:25,
from RcppExports.cpp:4:
../inst/include/ensmallen_bits/problems/fonseca_fleming_function.hpp: In member function ‘typename MatType::elem_type ens::test::FonsecaFlemingFunction::ObjectiveA::Evaluate(const MatType&)’:
../inst/include/ensmallen_bits/problems/fonseca_fleming_function.hpp:74:57: error: call of overloaded ‘sqrt(int)’ is ambiguous
return 1.0f - exp(-pow(coords[0] - 1.0f / sqrt(3), 2) -

https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/RcppEnsmallen-00install.html

Also, removes an extra negative sign between x1 and x2 addition.

[zoq]

Looking at the error message: ‘sqrt(int)’ is ambiguous I think the static_cast is not necessary?

[coatless]

It's probably overkill, I can remove if need be.

[rcurtin]

We don't actually know what coords[0] is, so I might suggest using MatType::elem_type maybe like this:

typedef MatType::elem_type T;
return T(1) - exp(-pow(coords[0] - T(1) / sqrt(T(3)), T(2))
    - pow(coords[1] - T(1) / sqrt(T(3)), T(2))
    - pow(coords[2] - T(1) / sqrt(T(3)), T(2)));

Or, something like that could work. Basically the idea is to force every internal type inside the expression to be the same as MatType::elem_type.

[coatless]

@rcurtin I agree with a type cast. That said, we input into pow() and sqrt() may be either float, double, or long double per their function definitions.

So, MatType::elem_type includes unsigned int and int.

short		long
mat	=	Mat<double>
dmat	=	Mat<double>
fmat	=	Mat<float>
cx_mat	=	Mat<cx_double>
cx_dmat	=	Mat<cx_double>
cx_fmat	=	Mat<cx_float>
umat	=	Mat<uword>
imat	=	Mat<sword>

[rcurtin]

Ah, good point! In this case, I'd be fine forcing to double like you suggested.

[zoq]

Ready from my side, thanks.

[mlpack-bot]

Second approval provided automatically after 24 hours. 👍

[rcurtin]

Thanks! 👍

@coatless want to help test the automatic release system by updating your local repo to master after this merge, then using the script scripts/ensmallen-release.sh coatless 2 14 2? If not it's perfectly okay. 😄

[coatless]

@rcurtin after updating my fork, I'm getting:

(base) ➜  ensmallen git:(master) ./scripts/ensmallen-release.sh coatless 2 14 2
git diff returned a nonzero result!

[rcurtin]

Hmm, is it a pristine copy of master? If you had some local change, you could always do git stash or if you don't need to keep it, just git reset --hard origin/master. Then I think the script might work. 😄

[rcurtin]

Thank you for helping play with this script, by the way. The more people use it, the more robust it gets. :)

[rcurtin]

@coatless I just went ahead and ran the script. I think in a future release I'll document that git diff error a bit better. 👍

[coatless]

@rcurtin sorry for the delay, start of new semester. RE: git diff, it's because of the zsh shell or git version available on mac. For some reason, it is not reading one of the bquotes properly.