Relax most constraints on binary digit count

[ckormanyos]

Relax most of the constraints on the binary digit count allowed in uintwide_t. Add support for bit counts that also contain fractional parts of a limb such as uint99_t, etc. To be decided is storage left-shifted to MSB or resting on the LSB.

[ckormanyos]

This is also needed if uintwide_t eve provides the fundamental data type for a big floating-point type.

[ckormanyos]

For the moment, we will stick with:

• Width can be while being 16, 24, 32 or larger.

Applications needing finer sub-limb bit counts must shift and mask on their own.

[johnmcfarlane]

I'm curious to know three things:

1. What is the need of these very specific sub-limb widths, 16, 24 and 32? This whole constraint seems very puzzling and I wonder if it can be expressed a different way so the reason is more clear to a naive user like myself.
2. What about types built from non-standard integers, or integers with odd (literally odd!) widths? What if there was a 13-bit integer in a DSP and you wanted to emulate a 39-bit integer?
3. Do you plan to move to NumLimbs insteadof Width2 for the parameter? If so, that should make the implementation noticeably cleaner. (I'm for it.) If not, then surely being able to specify any width at all would be half of the benefit to the user of choosing Width2.

[ckormanyos]

1. What is the need of these very specific sub-limb widths

To 1:
It actually springs from a weakness or perhaps a design of this original work. The wide_integer project actually comes from original very early C++ work I did in the 1990s. In that work I had all the arithmetic worked out for 2^n bit counts, unsigned. As time went on and the need for a prototype unsigned integer type arose in my life, I reachec back to that ancient work and adapted it to C++11 template design. I found 2^n to be quite a constraint. So I increased the granularity. the exact constraints come from a compromise between all bit counts allowed and only 2^n.

This also touches on point 3 since, if I move to NumLimbs, some of the compile-time checks can be removed.

2. What about types built from non-standard integers, or integers with odd (literally odd!) widths?

To 2:
Literally nothing. I simply disregard those cases and assume the client will mask the unused bit(s). A future design would like to remove this constraint. That was the original point of this issue, which I just closed out of convenience, but did decide to re-open.

3. Do you plan to move to NumLimbs insteadof Width2 for the parameter?

To 3:
My favorite would be to retain something like the Width2 parameter of a bit count and remove the constraint, ultimately allowing any bit count from, say, something like 3 to 30 million (after FFT multiply, Toom-Cook, sub-quadratic division).

At the moment, I need to study up on 3 a bit. And I do not really want to tackle that at the moment, as my brain needs to figure out an easy way to program the masking and shifting.

Anyway i hope i answered some stuff, and ultimately, this does motivate me to re-open the ticket.

[johnmcfarlane]

Great answers, thanks! I'll concentrate on 3...

And I do not really want to tackle that at the moment, as my brain needs to figure out an easy way to program the masking and shifting.

No hurry here. Just some speculation and to join in the activity of figuring out.

My favorite would be to retain something like the Width2 parameter of a bit count and remove the constraint, ultimately allowing any bit count from, say, something like 3 to 30 million (after FFT multiply, Toom-Cook, sub-quadratic division).

That leads on to an important clarifying question: are there any operations or algorithms (e.g. the ones you mention) which benefit from knowing the exact number of bits the user requires? IOW, are there operations which will be faster if you didn't round up Width2 to the limit of the number of Limbs? E.g. are there operations for which uintwide_t<127, uint32_t> is more efficient than uintwide_t<128, uint32_t>?

[ckormanyos]

There is no perceived interest in this warranting the coding effort. Closed with no intent to re-open.