Re: [boost] Looking for help on preparing for review

Subject: Re: [boost] Looking for help on preparing for review
From: Damian Vicino (damian_at_[hidden])
Date: 2018-06-18 20:31:48

Hi Jeff,
Thanks for the comment, I will definitely work in a good answer and add the
question to the FAQ in the manual.

In general, the main differences I see are:
- Flexibility and more granular control: FPE is for all or nothing, while
safefloat can be used to enforce some checks for a subgroup of all the
floating point variables in the program or library. Also, safe_float may
provide different checks in different contexts, not an all or nothing flag.
- More options on how to react to failure. FPE will abort, while safefloat
library provides different strategies to act when a check fails, it may be
the case that you can expect a check to fail under certain conditions
(exceptional behavior). An alternative would be to manually check flags
after each operation, in place of doing that, safe float could throw an
exception that can be handled, or return an unexpected_value that can be
also handled.
- Multiplatform/compiler: safe_float is suppose to work in any compiler
implementing the c++ standard.

A real use case I had was that I wanted to capture the check failures in
logs but not failing in the wild (given service was running without check
for long time). I added safe_float with the "on_fail_cerr" policy, and that
provided some valuable insights in logs attached to bug reports. At the
time, we already diagnosed the bug and this only added more data to support
the bug, but having safe float before start could allow us to catch the bug
long time before.

Does this make sense?

Best regards,
Damian

2018-06-18 14:02 GMT-04:00 Jeff Hammond <jeff.science_at_[hidden]>:

> Maybe I am dense, but what is the difference between this and what I can
> get from e.g. the Intel compiler by enabling FPEs?
>
> Thanks,
>
> Jeff
>
> -fp-trap=<arg>[,<arg>,...]
>
>           control floating point traps at program start.  <arg> can be of
> the
>
>           following values
>
>             [no]divzero   - [Do not] trap on division by zero
>
>             [no]inexact   - [Do not] trap on inexact result
>
>             [no]invalid   - [Do not] trap on invalid operation
>
>             [no]overflow  - [Do not] trap on overflow
>
>             [no]underflow - [Do not] trap on underflow
>
>             [no]denormal  - [Do not] trap on denormal
>
>             all           - enable trap on all of the above
>
>             none          - trap on none of the above
>
>             common        - trap on most commonly used IEEE traps
>
>                             (invalid, division by zero, overflow)
>
>
>
>
> On Sun, Jun 17, 2018 at 8:53 PM, Damian Vicino via Boost <
> boost_at_[hidden]> wrote:
>
>> Hi,
>> I'm preparing my library safe_float to be proposed for review.
>>
>> The library was born in the GSOC2015, but it never reached a review ready
>> state. My plan is to change that in the next few months.
>>
>> At this point, I'm looking for some volunteers to proof-read the
>> documentation. Code is going through major rewrite, and I will send
>> another
>> mail looking for help with reviewing the code when that is done.
>>
>> The most current documentation can be read directly from the web here:
>> https://sdavtaker.github.io/safefloat/
>>
>> Any comment is appreciated.
>>
>> Best regards,
>> Damian
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman
>> /listinfo.cgi/boost
>>
>
>
>
> --
> Jeff Hammond
> jeff.science_at_[hidden]
> http://jeffhammond.github.io/
>