The bit* functions, in contrast to the other numerical functions, don't appear to check for overflow, i.e. (bit-test 13 200000) returns true.
It would be nice if the behaviour would fit the other numerical operators, i.e. throw on overflow and provide a variant that doesn't, and one that works with arbitrary precision, also not currently supported:
(bit-test (bigint 13) 20000), (bit-test (biginteger 13) 20000) throw IllegalArgumentException.
I have a patch that allows bit operations to be applied to BigInts (long + BigInteger).
(previous content deleted)
From the description of this issue, and “overflow” for a bit operation on a long-integer is when a specified bit position is greater than 64 (i.e. 1 << 6, the bit-length of a length of a long integer). In Java, if such a bit-position is specified, it is truncated to its first 6 bits.
As such, the behavior of bit-test is consistent with the java language, so I don’t think this behavior should change.
However, in my patch, each bit-operation on long-integers that specifies a bit-position (i.e. bit-set, bit-clear, bit-flip, bit-test, bit-shift-left, bit-shift-right) have corresponding companion bit-operations that do not truncate the bit-position to the first 6 bits (bit-set', bit-clear', bit-flip', bit-test', bit-shift-left', bit-shift-right' . Instead, if needed, they convert the result of the operation to a BigInt (that uses a BigInteger under the hood).
The convention of adding an apostrophe to the end of the operation name come from arithmetic operations like + and +', and * and *'.
Hi, Alex. Wasn’t sure who to ping on this –
”Reporter” is “import”, so guessing this issue was submitted on a non-git repo before it was imported to “git”
Do you know who I might chat with about this issue?
Thanks.
-- Harmon
Reporter is import as it was imported from a prior jira system and the user was not imported, but all of the info should be here. What did you want to chat about?