What determines if integers are formatted as hex or not in the REPL?

New to Julia
1

Why is one printed as hex and the other not?
Also, why does the line number not increase after the first assignment? (doesn’t seem to always do that - just noticed it)

   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.0-DEV.368 (2023-08-30)
 _/ |\__'_|_|_|\__'_|  |  Commit 197180d858 (0 days old master)
|__/                   |

In [1]: a::UInt32 = 100
Out[1]: 100

In [1]: b::UInt32 = 0xfe0
Out[1]: 0x0fe0

EDIT: perhaps it is the UInt32 type? In a new session, adding a to a gives:

In [1]: a::UInt32 = 100
Out[1]: 100

In [2]: b::UInt32 = 0xfe0
Out[2]: 0x0fe0

In [3]: a + a
Out[3]: 0x000000c8
2

Because the value of an assignment expression is the right-hand side. So, in an expression like a::UInt32 = 100, the right-hand side is the (signed) Int literal value 100, which prints in decimal by default. Whereas unsigned values print in hexadecimal by default, so if you show a or 0xfe0 they display in hexadecimal:

julia> 100
100

julia> a::UInt32 = 100
100

julia> a
0x00000064
4 Likes
3

And it does indeed mention that fact in the documentation. I overlooked.

4

It’s because the right-hand side isn’t unsigned in the former case, and it (using its type) is shown (there Int64). And what is show is nothing related (or needs not be) to UInt32.

I started explaining this way, what I assumed you were asking about (I had to stare at this for a while after I realized it wasn’t your question):

It’s the U for Unsigned. It’s by design, while somewhat controversial, but can be justified.

Maybe helpful to see if you had evaluated a right-hand-side, and seen the cast to UInt32 fail:

julia> a::UInt32 = typemax(Int64)
ERROR: InexactError: trunc(UInt32, 9223372036854775807)