Re: [boost] [safe_numerics] Last three days

Subject: Re: [boost] [safe_numerics] Last three days
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-03-10 19:25:33

Update: I now have a version which builds and runs all the tests with 
VC2017, the fixes required are here: 
https://github.com/robertramey/safe_numerics/pull/33

Hopefully this will encourage a few other people to give this a try.

The one exception is test_cast.cpp which triggers the MSVC runtime 
checks due to the use of an unitialized variable in the test suite, 
which should obviously be fixed.

I also noticed that test_z.cpp has no content: it's all #if'ed out.

> Perhaps you might take a different tack.  I've spent a little time 
> looking at the boost multi-precision library with the eye of 
> incorporating it into the safe numerics testing.  In the course of 
> doing this a couple of interesting things occurred to me.
>
> a) would safe numeric types inter-operate with safe numerics types? 
> They should - but I haven't actually tested this.  Whenever I fail to 
> test something - there's almost always a bug in it.
>
> b) would safe<T> work if T is one of the types defined by boost 
> multi-precision?  This is unclear to me.  safe numerics presumes that 
> the largest types available are std::uintmax_t and std::intmax_t .  
> It's easy to imagine altering this presumption to use types defined by 
> the user to be types like boost::uint512_t or... . I think this would 
> work with minor changes - such a combination would open up whole new 
> territory.
>

There is overlap between the two libraries here: class cpp_int already 
has built-in overflow checking that allows it to operate as a checked 
integer type already.  The issue here, is that a generic test for 
possible overflow is likely to be ruinously expensive compared to 
built-in support - in fact built in support has basically zero cost 
since the presence of overflow is already right there in the 
multiprecision-algorithm, as in "we have more bits in the result but no 
where left to put them".  One thing I want to at least try and do, is 
figure out whether your extension-API's are suitable for hooking into 
this along with assembly code overflow checks for native types.

> Maybe if you confined the scope of your review to issues such as the 
> above you could save a lot of time and bring up issues that others are 
> not in a position to do.
>
> Finally, my biggest disappointment in all this has been my inability 
> to get people to take this whole effort seriously. That is, to even 
> admit that there is even a problem.  It's inexplicable and 
> disheartening to me that one can write something like x + y and not be 
> confident that the result actually equals x + y. Especially in light 
> of the fact that we're using C++ to make flying cars - not just 
> websites.  I feel that for the first time in 60 years we're in the 
> position of making demonstrably correct software - and no one cares.  
> It's very frustrating.
>
> I so much appreciate the interaction I have with my Boost soulmates. 
> I'm not sure what I would do with this.

Build it and they will come ;)

Best, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com