Change printing of Unsigned types to decimal base

[AzamatB]

After consulting on the slack channel, I am still not aware of a good reason why Unsigned types are printed in the hexadecimal base (looks like it was a decision that inherited from C). But there is a number of reasons to represent them in the usual decimal base. I associate them with natural numbers, but their idiosyncratic representation makes them unintuitive to interpret, so I end-up opting for Integers just for the sake of decimal representation even when only Unsigned would suffice.

[yuyichao]

Title and post content edited. Printing is debatable (though has nothing inherited from C). Representation (storing) is not.

[mbauman]

The "idiosyncratic representation" of unsigned integers mirrors their idiosyncratic behaviors: whereas signed integers overflow at numbers far away from zero, unsigned integers wrap around right where things get interesting — and where overflow bugs are much more likely to occur. All it takes is writing a - b in the wrong order. As such, I find general arithmetic on unsigned integers or the "enforcement" of a domain constraint with them to be fraught with trouble. The exception, of course, is bitwise arithmetic where you're explicitly treating the integer as a "bag of bits" and thus don't need to worry about overflow (or explicitly rely upon it). So we emphasize that use-case in its printing.

I very much appreciate the current printing and I think many contributors feel similarly. In fact, I would go so far as to say that it's working as designed if it pushed you to use signed integers. :)

In other languages: https://stackoverflow.com/questions/30395205/why-are-unsigned-integers-error-prone https://www.youtube.com/watch?v=wvtFGa6XJDU

[KristofferC]

Personally, I am annoyed by the printing as well and don't see a good reason for printing unsigned integers in hex. If one want to read numbers in hex, we have functionality for that (string(x; base=16)). The argument that they are somehow printed badly on purpose to make them annoying enough as to not be used feels a bit patronizing.

[JeffBezanson]

I don't think the point is to make them annoying, it's just to indicate type information, which show and display generally do. print already prints unsigned integers in decimal.

[KristofferC]

If it is about showing type information, then suffix with a u or something instead seems like a simpler thing than to change the base.

[StefanKarpinski]

Let's revisit this in a couple of years when we're considering 2.0. Personally, I'm quite pleased with the way this works, but of course, I designed it in the first place. Reasoning given in quite possibly my least popular StackOverflow answer—https://stackoverflow.com/a/27351455/659248:

This is a subjective call, but I think it's worked out pretty well. In my experience when you use hex or binary, you're interested in a specific pattern of bits – and you generally want it to be unsigned. When you're just interested a numeric value you use decimal because that's what we're most familiar with. In addition, when you're using hex or binary, the number of digits you use for input is typically significant, whereas in decimal, it isn't. So that's how literals work in Julia: decimal gives you a signed integer of a type that the value fits in, while hex and binary give you an unsigned value whose storage size is determined by the number of digits.

Or to put it another way: if you're annoyed by the printing of an unsigned integer, you should probably be using a signed integer type instead.

[PeterJacko]

I need to store in a very large array a set of numbers that can only take 4 integer values (say 0, 1, 2, 3). I want to minimize the memory this array takes. So I essentially need an array with UInt2 elements, but this is not available in Julia. I use UInt8, using which I can store 4 numbers in every element, by encoding them (multiplying them by 1, 4, 16 and 64 respectively). I couldn't use Int8 with such a simple encoding (I would need to add these to -128). The fact that I was forced to use hex was quite annoying and error-prone at the beginning, though I have now got used to it.

If using hex is the price for achieving better performance, I don't mind paying it. But it doesn't look like the arguments of anyone here are to improve performance or memory requirements.

[yuyichao]

If using hex is the price for achieving better performance

This is about printing only. There's nothing performance or memory related about this. The type available should not have any limitation on your storage format. Depending on you need, there are many alternative ways to be more memory efficient and if you need help, please ask on discourse instead.

[mgkuhn]

I find the hexadecimal representation of unsigned integers pedagogically very useful, and very much hope that future versions of Julia keep it that way. It is a common beginner's mistake to use unsigned integers merely because the programmer initially thought that the variable will never hold negative values. Only later do they discover that these variables will then be used in differences, or compared with other expressions (such as differences) that may be negative, and therefore require signed comparison, and then a whole world of pain emerges from unsigned types because understanding the exact overflow behaviour of mixed-signedness integer arithmetic becomes very complex, unintuitive and error prone.

It is much better to always stay with signed integers, unless you absolutely can't avoid unsigned-integer operations. That's why some programming languages newer than C/C++ (most notably Java) even avoided support for unsigned integer types.

There are only very few good reasons for ever using an unsigned integer type:

• If for memory reasons the storage type has to be very small, sometimes the range extension provided by the most significant bit really can make a difference to the application. This is usually only the case for the smallest integer types, e.g. 8-bit pixels in graphics, and the actual arithmetic is usually still done in a larger signed type.
• If an unsigned type was already specified in some external data format or interface (e.g., a protocol header), your standards-conformant implementation must work correctly all the way to the highest possible integer number. (Sadly some authors of such specifications also don't understand that requiring the MSB of a 32-bit or 64-bit field to remain zero would have made its safe and correct implementation and verification so much easier.)
• The variable contains not a number but a sequence of bits, and unsigned arithmetic allows you to perform some required operation on this bit sequence faster.

In particular for the last case, hexadecimal display of such values is usually more convenient anyway.

Please keep the display of unsigned integers hexadecimal in all future generations of Julia, to deter your children and your children's children from using them unnecessarily. It's not a bug, it's a wonderful feature to let programmers know that they are probably doing something questionable.

[StefanKarpinski]

Yes, very well put. I think we can safely close this. The answer to this "problem" is that if you want something that prints as decimal then you should be using a signed integer type. The usual reason people use unsigned integer types is because they believe that it's a better choice when a value is not supposed to be negative. However, that isn't true—it's almost always still a better to use a signed integer type. As you say, it often happens that you were shortsighted about not needing negative values, and even if you never need negative values for correct code, using a signed integer type allows correctly diagnosing when a negative value has mistakenly been produced (e.g. someone wrote a - b instead of b - a), whereas if the type is unsigned, the only hint of what the bug might be is that you got a suspiciously large value.