Thanks Matt. That's a very good explanation about the internal bit representation of integers and answers perfectly my question. I really appreciate your help in understanding these operations.
Cheers, Pablo On Wed, Jul 26, 2017 at 2:07 PM, Pablo Rozas Larraondo < p.rozas.larrao...@gmail.com> wrote: > Thanks Bakul, I also understand now what Matt Harden was referring to with > his comment. At a bit level both operations cause the same effect on the > underlying bits of the variable but it's meaning changes depending on the > type. All clear! > > Cheers, > Pablo > > On Wed, Jul 26, 2017 at 1:51 PM, Bakul Shah <ba...@bitblocks.com> wrote: > >> [Sorry, didn't see your original response] >> >> In the Go *language* (not just the compiler), when x is an unsigned int, >> -x is treated as a "shorthand" for ^x+1. Another interpretation is that for >> finite ints all arithmetic operations are modulo the word size. Thus -1 >> modulo 2^64 is 0xffffffff. You might even say that a 2's complement >> machine's native int type is an unsigned int! It is just that most >> arithmetic operations set relevant condition codes (or equivalent) that >> allows you (and the compiler) to interpret an int as a signed int or an >> unsigned one. >> >> I would suggest reading up on how computers do arithmetic. Programming >> languages are merely syntactic sugar on top of processor instruction sets >> :-) >> >> On Jul 25, 2017, at 8:16 PM, Pablo Rozas Larraondo < >> p.rozas.larrao...@gmail.com> wrote: >> >> Ok, I might be understanding this differently then: >> >> The -1 * x operation cannot be defined for unsigned integers as -1 >> overflows. Therefore, -x in the case of unsigned types is interpreted >> differently by the compiler, resulting in a ^x + 1 operation. Is that a >> correct assumption? >> >> By the way, yes, the title should say Bit instead of Byte, sorry about >> the confusion. >> >> On Wed, Jul 26, 2017 at 11:35 AM, Matt Harden <matt.har...@gmail.com> >> wrote: >> >>> Both statements are true for both signed and unsigned integers. >>> >>> On Mon, Jul 24, 2017, 04:11 Pablo Rozas Larraondo < >>> p.rozas.larrao...@gmail.com> wrote: >>> >>>> Thanks Bakul, I think I have a better understanding of what's going on >>>> after reading your response. >>>> >>>> Is it correct to say that the Go compiler treats the prepended minus >>>> sign differently depending on the variable being a signed or an unsigned >>>> integer? >>>> >>>> By looking at this example: https://play.golang.org/p/feqQsuPkqk >>>> >>>> It seems to me that in the case of an unsigned integer it's treated as >>>> a bitwise operation : -x == ^x + 1 >>>> But for signed integers -x == -1 * x >>>> >>>> Cheers, >>>> Pablo >>>> >>>> >>>> >>>> On Mon, Jul 24, 2017 at 5:36 AM, Bakul Shah <ba...@bitblocks.com> >>>> wrote: >>>> >>>>> This is a standard trick to find the least significant set bit in a >>>>> word. Only works for 2's complement numbers! >>>>> -x == ~x+1 >>>>> For example: x = 00110000b (24), ~x+1 = 11001111+1 = 11010000. Adding >>>>> them yields 00010000; thus only the least significant set bit remains set. >>>>> >>>>> Note that func LSB(x uint64) uint64 { return x&-x } works too. In >>>>> your example you get an error because in Go literal constants are untyped. >>>>> It is a pragmatic decision -- see https://blog.golang.org/constants >>>>> >>>>> On Jul 23, 2017, at 5:50 AM, Pablo Rozas Larraondo < >>>>> p.rozas.larrao...@gmail.com> wrote: >>>>> >>>>> I have seen Go code using this function to find out the least >>>>> significant byte of unsigned integers: >>>>> >>>>> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) } >>>>> >>>>> This function works fine but I wonder why, if call the same AND >>>>> operation, it results in an error: "constant -X overflows uint64" >>>>> >>>>> Here is a playground example to illustrate this: >>>>> https://play.golang.org/p/_0EYtlLnmG >>>>> >>>>> Does anyone know what changes when -uint64() is called in a return >>>>> statement? How a negative uint should be interpreted? >>>>> >>>>> Thank you, >>>>> Pablo >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
