Why don't languages that have big integer support have unsigned versions?

Question

A cursory glance at C#, Java, and other languages indicates this is not a feature that's required. I tried searching for justification for this maybe from a language design team or blog, but I haven't found anything that explains why such a type is ignored.

My current best guess is applications that use big integers wouldn't save or see noticeable performance benefits so it's left out.

Are there any languages that do support both signed and unsigned big integers? Is there any written justification or mailing list posts that describe why or why not such a feature was added or not included?

Answer 1

If you have a use case where you never have to deal with negative numbers inside of any big integer calculation, then you could use the signed big integers implementation as well, and your performance guess is what I would expect, too, the performance differences would most probably be negligible.

If you have a use case where negative intermediate results can occur, but you want them to "wraparound" to some positive value, then in a big integer context it is not inherently clear what the result should be. For example, the outcome of "4 -5" in a 32 bit unsigned integer context is typically "2^32-1" (as long as your environment does not throw an underflow error). What should it be in a context where there is no such upper limit of 32 for the number of bits?

That makes it hard to create a useful specification of how general purpose unsigned big integer should work, assumed one wants to make this a universally useful too.

Of course, this problem could be solved by introducing an artificial, configurable "maximum bitsize" into the unsigned big integer implementation, and I would be astonished if not someone somewhere in the past had implemented such a thing. However, I think authors of widely used general purpose libraries or languages will think twice if implementing such a specific requirement is worth the hassle and if there will be enough applications to justify the additional development and testing effort.

Answer 2

The original reason to have unsigned integers in a language in the first place is to extend the numeric range of a fixed-size type upwards at the cost of limiting it downwards. Beneficial effects such as sane semantics of bitwise operations (in C) or implicit enforcement of a non-negative constraint are not the primary reason.

Big integers do not have the problem of insufficient range, because they grow as needed, and saving that one bit is just not worth it.

Answer 3

One of the key advantages with a (for example) 32 bit unsigned integer versus a 32 bit signed integer is overflow. Fixed precision unsigned integers operate via 2ⁿ arithmetic, a specialized form of clock arithmetic. While this may be counterintuitive, it cannot overflow. Fixed precision signed integers, on the other hard, pretend to operate via the standard rules of arithmetic we learned as children. Sometimes this pretending fails.

This advantage disappears with extended precision arithmetic. Extended precision implementations successfully use the elementary rules we learned as children, to within the limits of computer memory. On the other hand, the clock arithmetic used in fixed length unsigned integers make no sense in extended precision arithmetic. The sum of two well-implemented bignums is a bigger bignum. The only risk is running out of memory. The difference between a pair of bignums also is not a problem. Clock arithmetic makes no sense in the domain of extended precision arithmetic.