Boost logo

Boost :

Subject: Re: [boost] Looking for help on preparing for review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-06-19 06:15:25


2018-06-18 22:31 GMT+02:00 Damian Vicino via Boost <boost_at_[hidden]>:

> 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?
>

It makes sense for me. Again, this explanation is worth adding in the docs
under a section like "why use this library rather than what we already
have".

Regards,
&rzej;

>
> 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/
> >
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk