With this change we get a *desired* compile time failure when we are passed type `T` that is not implicitly convertible from `int` but is explicitly convertible. Now, we make an implicit conversion from `int` a requirement and refuse to compile otherwise.
This addresses an issue where the user gives us a type `T` with non-intuitive construction from `int`.
Prior to this change, in floating-point computations, in the case
where we work for types where std::numeric_limits are not specialized,
funcitons min() and max() from std::numeric_limits<FPT> are nonetheless
instantiated and return FPT(0). While the result is never used in run-time,
this may still trigger a compile-time failure.
After this change, the paths for the cases where std::numeric_limits are not
specialized are handled by separate specializations rather than run-time if
statements.
Rationale:
Because we are not using the literal of type double, we avoid the bug where `FTP(0.01)` is evaluated as `FTP(int(0.01))` for FPT types that do not offer a conversion from `double`.
I do not use an explicit cast `v / FPT(100)` in order to allow the compiler to see that we are dividing by the integer, and engage optimizations for that case, if any.
By `v / 100` I require that conversion from int to FPT is implicit, and thereby avoid executing explicit constructors, which may have non-conversion semantics.
To the best of my knowledge, `v / 100` is not less accurate than `v * 0.01`. It may be slower, but given that this is evaluated in BOOST_TEST, which does lots of ops on IO streams, this should be negligible; plus, we are affecting only a percentage tolerance manipulator -- not the floating-point comparison itself.
Changed the occurences of FPT() to FPT(0). Since we expect a construction from int anyway,
and since the previous implementation assumed that the default constructor initializes to
numeric vaue zero, the change appears uncontroversial. What we gain, is that the default
ctor is no longer required. The FP algos work for non-default-constructible types.
