Subject: Re: [boost] Looking for help on preparing for review
From: Damian Vicino (damian_at_[hidden])
Date: 2018-06-18 21:15:44
Thanks for taking the time for reading it. I will reply interleaved to your
2018-06-18 8:09 GMT-04:00 Andrzej Krzemienski via Boost <
> 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
> > 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.
> 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.:
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 -->
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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk