What you're getting confused by is that your literals above are still unsigned hex literals; but they are being applied to the negation operator, which doesn't do what you want. In essence, when you type "-0x7", it's getting parsed as "-(0x7)":
julia> 0x7 0x07 julia> -0x7 0xfffffffffffffff9 julia> -(int(0x7)) -7 Therefore I'd suggest explicitly making anything you want to express as a signed integer as decimal. Note that -0x7 == -int(0x7) == int(-0x7), so it's not like any information is lost here, it's just the interpretation of the bits that is different. On Sun, Dec 7, 2014 at 7:38 PM, Phil Tomson <philtom...@gmail.com> wrote: > > > On Sunday, December 7, 2014 5:08:45 PM UTC-8, ele...@gmail.com wrote: >> >> >> >> On Monday, December 8, 2014 10:21:52 AM UTC+10, Phil Tomson wrote: >>> >>> julia> typeof(-0b111) >>> Uint64 >>> >>> julia> typeof(-7) >>> Int64 >>> >>> julia> typeof(-0x7) >>> Uint64 >>> >>> julia> typeof(-7) >>> Int64 >>> >>> I find this a bit surprising. Why does the base of the number determine >>> signed or unsigned-ness? Is this intentional or possibly a bug? >>> >> >> This is documented behaviour http://docs.julialang.org/en/ >> latest/manual/integers-and-floating-point-numbers/#integers based on the >> heuristic that using hex is "mostly" in situations where you need unsigned >> behaviour anyway. >> > > The doc says: > >> This behavior is based on the observation that when one uses *unsigned >> hex literals* for integer values, one typically is using them to >> represent a fixed numeric byte sequence, rather than just an integer value. >> >> > > Hmm.... In the above cases they were signed hex literals. >
