Logic and bit shifting operators

[cymplecy]

I'm wanting to do some bitwise logical and/or operations and shifting bits left/right (e.g & | << >> operators)

I can't find a library with them in in - does it exist (or has someone already made some blocks in their own project that I can use?)

[jens]

nope, doesn't exist yet. I'm curious about your project...

[cymplecy]

I'm writing an animated GIF Decoder

Well, actually, I'm transcoding the one that I wrote for GP back in the day

I'll make up some basic ones and then publish them and we can get them refined

[pumpkinhead]

oh, well coincidentally i made some bitwise operators blocks two weeks ago because i was bored

Snap! 6.3.2 Build Your Own Blocks

[cymplecy]

Good job I asked then
So lets use this as a starting point for a possible Snap! library

Couple of points

1. Should we use symbols like other languages do - here is JS one
   
   

Note: We can't use all of these since ^ is already used in Snap!

2 Is your >> the same as JS >> ? because - I like my >> to be the same as a left shift and push zero's in, not try and maintain any signed leading bit

3. In my original GP byteToBits block - I return a list not a string

So list or string?

Should a generic number to bit pattern block like the one here, vary the length of the bits or should it be fixed at 8 bits or 32 bits (or even 64 bits) Or some sort of menu options (variable/byte/word/int,longint)

Should there be a specific number to byte block?

I'll stop now

[pumpkinhead]

All of the blocks use JavaScript so I think it'd be obvious that I will use JavaScript's >> for the >> block. The to binary block returns a string because I used Number.toString(2); or something like that I'm in a hurry right now.

And about the variable/fixed length or c++ type size menus, perhaps we could add a pad block that adds a certain character until the string is a certain length.

[bh]

You can't use names for the bitwise operators that conflict with the names for Boolean operators (or, and, not). The semi-official (Logo) names are
bitand
bitor
bitnot
ashift (arithmetic, shifts the sign bit down)
lshift (logical, doesn't)

I think these should actually be primitive but not strongly I guess.

I don't think convert to binary belongs in this library. Integers in Snap! are already in binary, even if they don't look like it. I take it your block reports a string of digit characters, and that's not what you give a bitwise operator as input. And also, it's such a great programming exercise to write...