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 21:15:44

Hi Andrzej,
Thanks for taking the time for reading it. I will reply interleaved to your
comments.

2018-06-18 8:09 GMT-04:00 Andrzej Krzemienski via Boost <
boost_at_[hidden]>:

> 2018-06-18 5:53 GMT+02:00 Damian Vicino via Boost <boost_at_[hidden]>:
>
> > 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.
> >
>
> Hi,
> Some comments from the perspective of someone reading the docs for the
> first time and trying to determine if this library would be useful.
>
> 1. The scope of the library.
> It is not immediately clear what the scope of the library is. "safe_float"
> resembles "safe_int", so my first thought is that safe_float does the same
> for floats as safe_int does for ints. This seems confirmed by the statement
> " Safe Float proposes implementing a drop-in replacement for floating point
> numeric data types guaranteing that, when used in expressions in a C++
> program, no incorrect arithmetic results will be produced without the
> developer awareness." But that could not be possible/meaningful?
>

Your initial impression is right. The goal is catching common errors or
"unexpected" behaviour from floating point uses.

>
> Type `int` can be thought of representing Integer numbers except that it
> _very occasionally_ overflows: we might want to intercept these occasions,
> but otherwise just let pretend `int` to be Integer number.
>
> But what mathematical concept does `float` represent? A Real number? Or a
> Rational number? It overflows very occasionally (and it makes sense to
> detect those occasions), but it stores the inaccurate results _all the
> time_. Trying to trap all these times is impractical: you will be reporting
> errors all the time. Wen I decide to use type `float`, by definition I
> accept (and desire) rounding errors.
>

I agree that use cases for catching the rounding are way less common than
others, and that makes a good cases not to check them by default. However,
the standard provides the flag "FE_INEXACT", so, if not adding complexity
to the implementation, I would like to have this particular check to
provide coverage of all std flags.

>
> You show examples where detecting overflow and underflow makes sense, and I
> accept these as motivation for the library. But reporting assignment of 0.1
> as an error is impractical. Maybe such library should only be checking for
> underflows/overflows and undefined values and nothing else?
>

I will set underflow/overflow/division_by_zero as default checks for all
operations, and allow to remove any other adding others to users when they
require to customize.

>
> Also, when quoting David Goldberg, the docs mention, "Signed zero: In some
> cases as discontinuous functions the negative zero have important use."
> which implies that the library will somehow try to address "issues" with
> negative zero, but I am not sure what these issues are, and the docs do not
> mention this case anymore.
>

Good catch, I summarized all the things mentioned in that paper to go over
the known problems of using raw FP, but I didn't mention that we are not
trying to address all the cases right away.

>
> 2. The concepts.
> There is a section Concetps but it does not describe the FPT concepts as I
> would expect, as other Boost Libraries do, e.g.:
> https://www.boost.org/doc/libs/1_67_0/libs/beast/doc/
> html/beast/concepts/Body.html
>
>
I will add this section.

> Also it is not clear whether safe_float only works for `float`, `double`,
> `long double`, or if it also works with my own float-like type?
>

I mentioned that library supports float, double, long double, and in the
future I plan to add support for multi-precision. I will make it more clear
from the start.

>
> Am I supposed to be able to build my own error-handling policies? I could
> not find in the docs how I would define and plug one.
>

Yes, I will add a short tutorial like text for this.

>
> 3. There is no synopsis of safe_float in the docs. (or of any other type.)
>
>
I will add.

>
> 4. Minor typeos in the initial page:
>
> "surprice " -> "surprise"
>
> " guaranteing" --> " guaranteeing"
>
> no_rounding-no_overflow_to_infinity  -->
>
> no_rounding,no_overflow_to_infinity
>

Fixing them.

>
> Regards,
> &rzej;
>

Thanks, I will try to address all this issues and come back with a new more
complete version of the doc soon.

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>