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 <i...@golang.org> wrote:
> On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane <driu...@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 <0xj...@gmail.com> 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 <driu...@gmail.com> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
