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

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@lists.boost.org>:

2018-06-18 5:53 GMT+02:00 Damian Vicino via Boost :

...

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