Subject: Re: [boost] Looking for help on preparing for review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-06-18 12:09:29
2018-06-18 5:53 GMT+02:00 Damian Vicino via Boost <boost_at_[hidden]>:
> 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:
> 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?
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.
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?
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.
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.:
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?
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.
3. There is no synopsis of safe_float in the docs. (or of any other type.)
4. Minor typeos in the initial page:
"surprice " -> "surprise"
" guaranteing" --> " guaranteeing"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk