Ravenwater
commented
3 years ago regarding a base class design: we have a new set of number systems, areal and bfloat, which use constexpr machinery to reduce the need for specialized classes as we have done for the current posit<> implementation. The current implementation is a bit-level implementation using bitset<>, and that has two drawbacks, one is that it is slow, and two bitset<> is not constexpr, so we can't support constexpr with the current posit classes.
To make posits work for real applications, we introduced the hand-coded specialized classes. On the roadmap is the task of bringing the posit implementation to use constexpr machinery. We should then benchmark that and see if is competitive with handcoded classes. If not, we continue to use handcoded classes, and if you have any ideas how to make that easy to manage, we would love a PR.
Dear devs.
I have been looking a little at performance of the library and the specialized code. I have a few comments in that regard.
I your article https://arxiv.org/abs/2012.11011, you state that posit<64,3> has almost the same performance as posit<32,2>, around 100M operations per sec. Was that analysis done with the current library? When I look into specialized/posit_64_3.hpp, it appears to be a copy of 8-bit posit.
So basically, you have a bunch of specialized posits.
there is a lot of common code shared between these specializations; I think this can be refactored (for example) into a base class. For example, boost's iterator adaptor https://www.boost.org/doc/libs/1_55_0/libs/iterator/doc/iterator_adaptor.html allows you to specialize a few functions and let the template do the hard work. Perhaps it doesn't even have to be a specialization of the posit class, but it could simply be posit_322 etc (yes, clients can't use the name posit, but will have to rely on a typedef, but in return the error messages will improve). When I diff some of the specialized posits, I do wonder if the whole thing cannot be defined in terms of the bits size, es-value, and perhaps other bit masks, shift-values etc. If special algorithms is needed per type, it should be possible to extract these along the lines of what iterator_adaptor does.
It would have been cute to define operator-=(r) as operator+=(-r), but I pressume that won't work because the numbers are not symmetric around 0?
The implementation of x <= y is a bit strange; why not just implement it as !(x > y) ?
kind regards
Thorsten