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 <driu...@gmail.com> 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.har...@gmail.com>
> 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 <driu...@gmail.com> 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 <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.
>
>
>
> --
> - 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.
>
--
Michael T. Jones
michael.jo...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
