Re: [boost] Safe Float design question

17 Jul 2018

      Hi Damian,
I may not be answering your question directly, but maybe the following will
help.

You mention checking things as:
- I would like to check there was no "overflow_to_infinite" in "addition
operations", otherwise I "throw exception"..
- I would like to check there was no "division by zero" in "division",
otherwise I will "log to cerr and ignore it".

The two checks are very different in nature, and I do not even think they
belong into the same library. The first check traps a situation that (1)
the programmer-user cannot control (you do not know in advance if the
operation would overflow, it is not a bug to cause overflow), (2) Type
double has an inconvenient way of handling the situation (does not report
an error), so you want your type to handle it better.

The later check checks for programmer mistakes. These mistakes should not
be handled at run-time, but corrected in the code (the overflow cannot be
easily corrected in the code), and it adds overhead for situations that do
not occur for correct programs. The precondition violation should be
handled by contract libraries: otherwise you are preventing static-analysis
tools and UB sanitizers from finding division-by-zero bugs.

Next, if you go with providing checks separately from the method of
reporting them:

using sf = safe_float;

You will loose the ability to report different kinds of errors in different
ways. You have to make the call: do you always want all checks to be
reported in the same way, or do you want, for instance to allow reporting
the inaccurate addition in a different way than overflowing to infinity? If
the latter, you will have to encode the method of handling inside the check:

using P = compose_policy<
  check_addition_overflow< report_throw_on_failure >,
  check_division_underflow< abort_on_failure >
...
;
The design, where I first need to write 10 lines to build a policy, and
then define a type:

using fp = safe_float;

seems the right choice to me. Of course, you should provide some predefined
policies, that would be most obviously chosen most of the time. (Like,
check and throw only underflow and overflow, check and abort only on
underflow and overflow).

Regards,
&rzej;

Finally
2018-07-17 4:18 GMT+02:00 Damian Vicino via Boost :
...
Hi,
I looking for some design advice.
The context:
- I'm revisiting SafeFloat after some time and, while doing so, I'm
rethinking all the decisions from the past. Idea is to sent for review in
the following months.
- The goal of the library is being a drop-in replacement for float, that
adds checks to floating point operations and reports when a check failed.
Without SafeFloat, someone could write something like this:
#include <iostream>
#include <limits>
#include <cfenv>
using namespace std;
int main(){
    float a = 1.0f;
    float b = numeric_limits<float>::max();
    feclearexcept(FE_ALL_EXCEPT);
    float c = a/b;
    if(fetestexcept(FE_UNDERFLOW)) { cout << "underflow result\n"; }
}
What I expect when using safe_float is to declare upfront "what checks" I
care about, "what operations" to check, and "what to do when a check
fails".
Some intention examples:
- I would like to check there was no "overflow_to_infinite" in "addition
operations", otherwise I "throw exception"..
- I would like to check there was no "division by zero" in "division",
otherwise I will "log to cerr and ignore it".
- I would like to check there was no "inexact" "addition", otherwise I
return an boost::unexpected.
I have at least 5 things to check (there is 5 flags in c++11::fenv). I have
at least 4 places to check (+/-/*//) and I want to keep what to do about it
customizable.
In addition, sometimes I want to check multiple things "overflow and
underflow", etc...
So, the question is how the user can pass all that information to the type
and it doesn't look as horrible nonsense.
My original option was:
int main(){
using CHECK = compose_policy::type;
using REPORT = report_throw_on_failure;
using sf = safe_float;
try{
   sf a = 1.0_sf;
   sf b = numeric_limits<sf>::max();
   auto c = a/b;
} catch (safe_float_exception e){
   cout << e.message(); //this outputs there was a underflow
}
}
Please comment in what you think about this way to use. Is there a better
way to specify the policies to apply that I should try?
Best regards,
Damian
I expect when using safe float to write some code like this:
int main(){
safe_float<float>
}
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/
mailman/listinfo.cgi/boost

Re: [boost] Safe Float design question

Andrzej Krzemienski