One thing that might be handy to convert some aspect of a number into a rhythmic value, perhaps the teletype could benefit from an operator to return the status of each bit in the number.
IF BIT 1 A: TR.P 1
IF BIT 2 A: TR.P 2
IF BIT 3 A: TR.P 3
IF BIT 4 A: TR.P 4
I understand that this could be done using existing syntax, but I think that the addition of cellular automata to teletype via the
CHAOS operator calls for an easier way to access the bits of a value.
Implemented for 2.2:
| A B
& A B
BSET A B
BCLR A B
BGET A B
would be great to also have a corresponding setter
bitwise ops, you mean? we’ve discussed this in the past and i think it’s a good candidate. so BIT is a bitwise AND, with a helper shift on the first arg.
i’d be more up for a straight bitwise AND, it’d be more flexible. ie
AND* 3 X
returns the two rightmost bits of X. i’m not sure how to differentiate bitwise vs. logical (logical ops already exist for these).
set bit 1 to 1:
X OR* 1 X
clear bit 8:
X AND* 128 X
X AND* LSH 1 8 X
GET* n X
SET* n X
CLR* n X
i really like the readability and user friendliness of
GET\SET\CLR. do we need to include
it would be great to also have regular bitwise ops though. maybe just
I vote for plain
CLR. If we need to make it more clear, maybe
I’m for this as well.
i think set/get/clr are way too ambiguous without adding an indicator that they are for bits.
BSET/BGET/BCLR are fine by me. so is
BGET 3 A is certainly more readable than
MOD RSH A 2 2
should it be
BGET n X or
BGET X n? the latter feels a bit more natural.
I guess the latter fits with the existing ops better, so it gets my vote.
that was my thought, since it matches
LSH\RSH X n and such.
Pull request #126 opened with this functionality.
Test build: teletype.hex (355.4 KB)
looked at the PR, couple of comments:
- it probably makes more sense for n to be 0 based
- should we also add a bitwise NOT? as
I can do bitwise NOT as
~, sure! Good call.
As to bit indexing, I don’t know why I was thinking it should be 1-based. Working between two programming languages crosses my wires about conventions sometimes.
I’ll wait for @tehn to weigh in, but you’re probably right.
yes, 0 based.
X & (1 << n)
bitwise not, excellent! to be clear, ~ only takes a single arg, yeah? if we’re going all the way, ^ for xor?
Re: bitwise not
Given that bitwise not of a signed integer is not very useful, maybe the not should be performed in an unsigned manner? I.e.:
sign = x < 0 ? -1 : 1;
x = ( ~ (x * sign)) * sign;
note this breaks for -32768
It’s an odd problem.
guess i’d vote for having it do the obvious thing - flip all the bits including sign.
~(-256) = 255
~(-2) = 1
~(-1) = 0
2’s-complement is standard enough that breaking it would violate principle of least surprise…
let’s see, the alternative:
would mean, in int16, that
~(-1) = -1 * (~1) = -1 * 0xfffe = … 2? i feel weird.
Alternate would be illogical, as would all negative numbers. I shouldn’t have written that up. It’s wrong and bad and it was too late in the day.
I thought that NOT wouldn’t make sense to users in a signed context, but I guess it only makes sense to use that along with BGET.
inverting all the bits makes most sense, when using bitwise ops i would likely treat values as 32 bit unsigned ints (say, as a way to pack 32 step trigger sequence into a pattern value).
edit: 16, not 32… coffee!
PR Updated with NOT and XOR, zero-based bit indexing.
Test Build: teletype.hex (356.0 KB)
Bitwise AND, NOT, OR and XOR would be really nice
They’re all there in 2.2-beta. Got hashed out in another thread. Full set:
BGET, BSET, BCLR, &, |, ~, ^