FAQ
Is this supposed to be legal in Go:

var x int32 = 3

fmt.Printf("%d", x & 0xFFFFFFFF)?

The language spec just says the bitwise operator "applies to integers only"
and
"yields a result of the same type as the first operand" that I can see, but
it's giving
me a compiler error:

./main.go:10: constant 4294967295 overflows int32

with go 1.6.2.

Is this a compiler bug, or am I missing something else in the spec that
makes it impossible
to mask out the high bit in a signed integer type without converting to an
unsigned equivalent first?

- Dave

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Jan Mercl at Jun 14, 2016 at 5:23 pm
    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to an
    unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave MacFarlane at Jun 14, 2016 at 5:45 pm
    What I'm not understanding is why that's not the case in this example. It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't 0xFFFFFFFF
    be coerced to a value of -1?
    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j


    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at Jun 14, 2016 at 5:48 pm
    The untyped integer constant 0xFFFFFFFF represents a positive number not
    representable by any int32 value.
    On Tue, Jun 14, 2016, 19:45 Dave MacFarlane wrote:

    What I'm not understanding is why that's not the case in this example.
    It's a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be coerced to a value of -1?
    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j


    --
    - Dave
    --

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rob Pike at Jun 14, 2016 at 6:00 pm
    Please read blog.golang.org/constants.

    -rob

    On Tue, Jun 14, 2016 at 10:47 AM, Jan Mercl wrote:

    The untyped integer constant 0xFFFFFFFF represents a positive number not
    representable by any int32 value.

    On Tue, Jun 14, 2016, 19:45 Dave MacFarlane wrote:

    What I'm not understanding is why that's not the case in this example.
    It's a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be coerced to a value of -1?
    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j


    --
    - Dave
    --

    -j

    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jun 14, 2016 at 6:16 pm

    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane wrote:
    What I'm not understanding is why that's not the case in this example. It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't 0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave MacFarlane at Jun 14, 2016 at 6:41 pm
    I'm not actually trying to do x & -1, that would be pointless, as you say.
    It was just
    the easiest way to demonstrate the behaviour that I didn't understand in a
    minimal
    way. I understand the problem now--I was thinking of 0x as a prefix
    representing a bitmask
    when used as a constant with a bitwise operation, while Go thinks of it as
    a prefix
    representing a hexadecimal number even in that context.

    What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
    variables. I don't
    want to lose the precision that x*y >> 6 would unnecessarily as x or y get
    large, so I wanted
    to extract the first 26 bits, multiply them, and then separately multiply
    the decimal portion and add
    it back shifted into the correct location.

    (Int26_6 is defined as `type Int26_6 int32`)
    On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor wrote:
    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane wrote:
    What I'm not understanding is why that's not the case in this example. It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec that
    makes it impossible
    to mask out the high bit in a signed integer type without converting to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Harden at Jun 14, 2016 at 7:41 pm
    Consider coercing them to int64, multiply, then shift and coerce back to
    Int26_6. I suspect that would be faster than splitting with shifts and
    ANDs, two int32 multiplies, shift and add.
    On Tue, Jun 14, 2016, 11:42 Dave MacFarlane wrote:

    I'm not actually trying to do x & -1, that would be pointless, as you say.
    It was just
    the easiest way to demonstrate the behaviour that I didn't understand in a
    minimal
    way. I understand the problem now--I was thinking of 0x as a prefix
    representing a bitmask
    when used as a constant with a bitwise operation, while Go thinks of it as
    a prefix
    representing a hexadecimal number even in that context.

    What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
    variables. I don't
    want to lose the precision that x*y >> 6 would unnecessarily as x or y get
    large, so I wanted
    to extract the first 26 bits, multiply them, and then separately multiply
    the decimal portion and add
    it back shifted into the correct location.

    (Int26_6 is defined as `type Int26_6 int32`)
    On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor wrote:

    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane <driusan@gmail.com>
    wrote:
    What I'm not understanding is why that's not the case in this example. It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side, if
    representable as such after the conversion. That's not the case in this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can
    see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec
    that
    makes it impossible
    to mask out the high bit in a signed integer type without converting
    to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    - Dave

    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave MacFarlane at Jun 14, 2016 at 8:09 pm
    You're right. I've already written it the ugly way, but at least it
    has the benefit of being generalizable to fixed.Int52_12,
    while there is no int128.

    Would a patch that adds a Mult receiver function to Int52_12 and
    Int26_6 be welcome in x/image/math/fixed? I've already
    worked out the stupid shifting/bitwise arithmetic so you don't end up
    with things like multiplying by fixed.I(1) overflowing. It seems
    like the type of thing that users of the package shouldn't have to
    derive from scratch if they just want to multiply 2 fixed point
    numbers.

    - Dave
    On Tue, Jun 14, 2016 at 3:41 PM, Matt Harden wrote:
    Consider coercing them to int64, multiply, then shift and coerce back to
    Int26_6. I suspect that would be faster than splitting with shifts and ANDs,
    two int32 multiplies, shift and add.
    On Tue, Jun 14, 2016, 11:42 Dave MacFarlane wrote:

    I'm not actually trying to do x & -1, that would be pointless, as you say.
    It was just
    the easiest way to demonstrate the behaviour that I didn't understand in a
    minimal
    way. I understand the problem now--I was thinking of 0x as a prefix
    representing a bitmask
    when used as a constant with a bitwise operation, while Go thinks of it as
    a prefix
    representing a hexadecimal number even in that context.

    What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
    variables. I don't
    want to lose the precision that x*y >> 6 would unnecessarily as x or y get
    large, so I wanted
    to extract the first 26 bits, multiply them, and then separately multiply
    the decimal portion and add
    it back shifted into the correct location.

    (Int26_6 is defined as `type Int26_6 int32`)
    On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor wrote:

    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane <driusan@gmail.com>
    wrote:
    What I'm not understanding is why that's not the case in this example.
    It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and right
    types. Untyped values will be coerced to the type of the other side,
    if
    representable as such after the conversion. That's not the case in
    this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to integers
    only" and
    "yields a result of the same type as the first operand" that I can
    see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec
    that
    makes it impossible
    to mask out the high bit in a signed integer type without converting
    to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Jones at Jun 14, 2016 at 8:43 pm
    I have fought this many times.

    What I almost always do is cast all variables involved as unsigned so that
    I can express the logical operations as desired. The exception is right
    shift which must be signed if the expected outcome for signed values is to
    happen.
    On Tue, Jun 14, 2016 at 1:08 PM, Dave MacFarlane wrote:

    You're right. I've already written it the ugly way, but at least it
    has the benefit of being generalizable to fixed.Int52_12,
    while there is no int128.

    Would a patch that adds a Mult receiver function to Int52_12 and
    Int26_6 be welcome in x/image/math/fixed? I've already
    worked out the stupid shifting/bitwise arithmetic so you don't end up
    with things like multiplying by fixed.I(1) overflowing. It seems
    like the type of thing that users of the package shouldn't have to
    derive from scratch if they just want to multiply 2 fixed point
    numbers.

    - Dave
    On Tue, Jun 14, 2016 at 3:41 PM, Matt Harden wrote:
    Consider coercing them to int64, multiply, then shift and coerce back to
    Int26_6. I suspect that would be faster than splitting with shifts and ANDs,
    two int32 multiplies, shift and add.
    On Tue, Jun 14, 2016, 11:42 Dave MacFarlane wrote:

    I'm not actually trying to do x & -1, that would be pointless, as you
    say.
    It was just
    the easiest way to demonstrate the behaviour that I didn't understand
    in a
    minimal
    way. I understand the problem now--I was thinking of 0x as a prefix
    representing a bitmask
    when used as a constant with a bitwise operation, while Go thinks of it
    as
    a prefix
    representing a hexadecimal number even in that context.

    What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
    variables. I don't
    want to lose the precision that x*y >> 6 would unnecessarily as x or y
    get
    large, so I wanted
    to extract the first 26 bits, multiply them, and then separately
    multiply
    the decimal portion and add
    it back shifted into the correct location.

    (Int26_6 is defined as `type Int26_6 int32`)
    On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor wrote:

    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane <driusan@gmail.com>
    wrote:
    What I'm not understanding is why that's not the case in this
    example.
    It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl wrote:

    All binary operators, except shifts, require identical left and
    right
    types. Untyped values will be coerced to the type of the other side,
    if
    representable as such after the conversion. That's not the case in
    this
    example.
    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane wrote:

    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to
    integers
    only" and
    "yields a result of the same type as the first operand" that I can
    see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec
    that
    makes it impossible
    to mask out the high bit in a signed integer type without
    converting
    to
    an unsigned equivalent first?

    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    - Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Michael T. Jones
    michael.jones@gmail.com
    http://www.google.com/profiles/michael.jones

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Jun 15, 2016 at 2:27 pm
    I do x & (0xffffffff - 1<<32).
    On Tuesday, June 14, 2016 at 1:44:14 PM UTC-7, Michael Jones wrote:

    I have fought this many times.

    What I almost always do is cast all variables involved as unsigned so that
    I can express the logical operations as desired. The exception is right
    shift which must be signed if the expected outcome for signed values is to
    happen.

    On Tue, Jun 14, 2016 at 1:08 PM, Dave MacFarlane <dri...@gmail.com
    <javascript:>> wrote:
    You're right. I've already written it the ugly way, but at least it
    has the benefit of being generalizable to fixed.Int52_12,
    while there is no int128.

    Would a patch that adds a Mult receiver function to Int52_12 and
    Int26_6 be welcome in x/image/math/fixed? I've already
    worked out the stupid shifting/bitwise arithmetic so you don't end up
    with things like multiplying by fixed.I(1) overflowing. It seems
    like the type of thing that users of the package shouldn't have to
    derive from scratch if they just want to multiply 2 fixed point
    numbers.

    - Dave

    On Tue, Jun 14, 2016 at 3:41 PM, Matt Harden <matt....@gmail.com
    <javascript:>> wrote:
    Consider coercing them to int64, multiply, then shift and coerce back to
    Int26_6. I suspect that would be faster than splitting with shifts and ANDs,
    two int32 multiplies, shift and add.

    On Tue, Jun 14, 2016, 11:42 Dave MacFarlane <dri...@gmail.com
    <javascript:>> wrote:
    I'm not actually trying to do x & -1, that would be pointless, as you
    say.
    It was just
    the easiest way to demonstrate the behaviour that I didn't understand
    in a
    minimal
    way. I understand the problem now--I was thinking of 0x as a prefix
    representing a bitmask
    when used as a constant with a bitwise operation, while Go thinks of
    it as
    a prefix
    representing a hexadecimal number even in that context.

    What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
    variables. I don't
    want to lose the precision that x*y >> 6 would unnecessarily as x or y
    get
    large, so I wanted
    to extract the first 26 bits, multiply them, and then separately
    multiply
    the decimal portion and add
    it back shifted into the correct location.

    (Int26_6 is defined as `type Int26_6 int32`)

    On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor <ia...@golang.org
    <javascript:>> wrote:
    On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane <dri...@gmail.com
    <javascript:>>
    wrote:
    What I'm not understanding is why that's not the case in this
    example.
    It's
    a 32 bit bitwise operation on a 32 bit signed type. Shouldn't
    0xFFFFFFFF be
    coerced to a value of -1?
    Why don't you just write -1?

    I don't actually understand what you are doing. Given an int32 value
    x, x & 0xFFFFFFF (assuming that were valid) is always simply x. What
    else could it be? If you want to mask out the sign bit you should
    write x & 0x7FFFFFFF.

    Ian

    On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com
    <javascript:>> wrote:
    All binary operators, except shifts, require identical left and
    right
    types. Untyped values will be coerced to the type of the other
    side,
    if
    representable as such after the conversion. That's not the case in
    this
    example.

    On Tue, Jun 14, 2016, 19:16 Dave MacFarlane <dri...@gmail.com
    <javascript:>> wrote:
    Is this supposed to be legal in Go:

    var x int32 = 3

    fmt.Printf("%d", x & 0xFFFFFFFF)?

    The language spec just says the bitwise operator "applies to
    integers
    only" and
    "yields a result of the same type as the first operand" that I can
    see,
    but it's giving
    me a compiler error:

    ./main.go:10: constant 4294967295 overflows int32

    with go 1.6.2.

    Is this a compiler bug, or am I missing something else in the spec
    that
    makes it impossible
    to mask out the high bit in a signed integer type without
    converting
    to
    an unsigned equivalent first?

    - Dave

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --

    -j



    --
    - Dave

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.



    --
    - Dave

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.


    --
    - Dave

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.


    --
    Michael T. Jones
    michae...@gmail.com <javascript:>
    http://www.google.com/profiles/michael.jones
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jun 16, 2016 at 12:17 am

    On Wed, Jun 15, 2016 at 6:08 AM, Dave MacFarlane wrote:
    Would a patch that adds a Mult receiver function to Int52_12 and
    Int26_6 be welcome in x/image/math/fixed?
    Yeah, I'd take that.

    For Int26_6, I'd convert to int64, multiply, then shift and convert
    back to Int26_6, as Matt Harden said.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 14, '16 at 5:16p
activeJun 16, '16 at 12:17a
posts12
users8
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase