Re: [boost] safe integer library -- the scope

Subject: Re: [boost] safe integer library -- the scope
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-12-11 17:11:30

2015-12-11 17:21 GMT+01:00 Robert Ramey <ramey_at_[hidden]>:

> On 12/11/15 7:07 AM, Andrzej Krzemienski wrote:
>
>> Hi Robert,
>>
>> It is great to see this library getting into Boost. It fills an important
>> gap, but it is only after a long while that I realized that, because the
>> introductory part of the documentation does not stress it enough, and in
>> fact it misled me a bit.
>>
>
> I'm not sure if you're referring to the documentation as it was when you
> posted your review or the documentation in it's current state.  When I read
> you're review I realized that I hadn't clearly isolated the concept of
> undefined behavior from that if incorrect arithmetic behavior.  I reworked
> a lot of the documentation based on your review.
>
> Also as I worked on the package it became clear to me that I had to be
> more ambitious to make the impact I wanted.
>

Yes, I am referring to the rewritten documentation. I observe that it has
changed significantly.

>
>
>> My understanding is that safe<int> represents a high level abstraction of
>> an integral number from mathematics: unlike raw type int, which represents
>> a set of allowed operations on the underlying processor.
>>
>
> Very well put.  I'll work that in somewhere.
>
> You could say that raw type 'int' is only needed to efficiently implement
>> higher level abstractions, like BigInt or safe<int> -- the two only differ
>> in trade-offs between efficiency and the range of values they can
>> represent.
>>
>
> Again correct.  The key concept is that our machines don't implement
> arithmetic.  It's up to us to find a way to make them do it.  Until we do,
> we'll be in a continuous battle to reconcile the differences between the
> arithmetic we think about and the bit manipulation that our machines do.
>
> I was missing this in the introduction. Instead I got a somewhat negative
>> impression that the goal of the library is to turn any UB into throwing
>> exceptions (and thereby prevent any UB-based static analysis from
>> detecting programmer
>> errors).
>>
>
> That wasn't all that in accurate.  When I started the library, I was just
> thinking I needed a hack to reduce my bug count.  I figured I could make a
> small class which would do the job and that it take a couple of days to
> make a cool little class.
>
> That was three years ago.
>
> As I started to patch up corner cases, I came to understand that one had
> to grab the stick from the other end.  That is, instead of trying to patch
> up C/C++ arithmetic to make it less error prone, start with arithmetic and
> "re-implement" it in terms of the operations that computer hardware
> actually implements.  Add to this two key requirements:
>
> a) do not ignore cases where the underlying hardware cannot produce a
> correct result.
>
> b) implementation must be as fast as possible
>

I was missing such strong statement from the first page: "This library does
not avoid some UB: it provides a higher level abstraction than 'int' even
if it has the same interface".

>
> I would like to see the library in Boost, although I must admit the other
>> parts do not sound that compelling as safe<int>.
>>
>
> what other parts?
>

1. safe_unsigned_range -- while I understand the idea behind it, I don't
think I would be inclined to use it. And also, I believe it addresses a
different problem, and could be handled by another library, like:
http://rk.hekko.pl/constrained_value/

2. safe<unsigned int> -- this looks suspicious. Unlike signed int, unsigned
int does not overflow. It is meant to represent the modulo arithmetic with
well defined result for any input values. If I do not want modulo
arithmetic, I would rather go with safe<int> than safe<unsigned>.

3. The docs mention a possible extension for safe<float>. I do not know
what that would mean. In the case of safe<int> I know what to expect: you
trap when I try to build value greater than INT_MAX  or smaller than
INT_MIN: nothing else could go wrong. But in case of float: do you trap
when I want to store:

safe<float> ans = safe<float>(1.0) / safe<float>(3.0);

?? 1/3 does not have an accurate representation in type float. But if you
trap that, you will be throwing exceptions all the time. So is it only
about overflow?

Regards,
&rzej