4

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?

  • 2
    Well, off the top of my head, it seems like an unsigned big integer would be essentially the same as a signed big integer except that you could drop the sign bit, and every subtraction operation risks an overflow. I can't think of any application where that would be a net win. – Ixrec Apr 15 '16 at 23:28
  • 1
    What behavior would you expect from an unsigned big-int if you calculate 0 - 1? What advantages would unsigned big integers have over signed big integers? – Bart van Ingen Schenau Apr 16 '16 at 6:55
3

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.

8

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.

  • 4
    Unsigned integers have different semantics than signed integers. Having that extra bit for size is less important than the semantic differences. – Robert Harvey Apr 16 '16 at 1:08
  • @RobertHarvey: I would say this is an additional property which might be important in some contexts, less important in others. – Doc Brown Apr 16 '16 at 8:35
  • 2
    Those semantics also don't affect big integers- for example overflow and underflow. – DeadMG Apr 16 '16 at 9:42
2

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 2n 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.