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.
