http://stackoverflow.com/questions/27349517/why-is-typeof-hex-or-binary-number-uint64-while-type-of-decimal-number-is-int64
Although I recall now that there was already a rationale for this behavior in the manual where it is described. On Sun, Dec 7, 2014 at 10:44 PM, Elliot Saba <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Sunday, December 7, 2014 5:08:45 PM UTC-8, [email protected] 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. >> > >
