bitand

Builtin index · Collections & strings

result = bitand(a, b)

Input: a, b · Output: result

What it is

a and b are numbers holding integer values.

Overloads

One call shape — this function is not overloaded.

Examples

From the documentation, and run by the build -- the output and the figure below are what the engine actually produced. Simplest first.

flags = bitand(12, 10)          # 8   -- bits common to both

print(flags)
print(bitor(12, 10))            # 14

print(bitxor(12, 10))           # 6

print(bitcmp(0))                # -1

print(bitshift(1, 4))           # 16  -- left shift

print(bitshift(16, -2))         # 4   -- right shift

print(xor(true, false))         # true

print(nand(true, true))         # false

print(nor(false, false))        # true

print(hex2dec("FF"))            # 255

print(dec2hex(255))             # "FF"

print(bin2dec("1010"))          # 10

print(dec2bin(10))              # "1010"

8
14
6
-1
16
4
true
false
true
255
FF
10
1010

from collections-strings

How it works

Bitwise ops (2026-08-23, Ahmed: "do we have & && | || xor bitxor bitor or bitand and nand nor"). Value has no separate integer type — everything is f64 — so these read each argument as an integer via int_arg (rejecting non-integral input rather than silently truncating it), do the op as i64, and hand back a Num. Deliberately builtins, not new &/|-family operators: and/or already mean logical and/or in Qu, so overloading &/| for bitwise would be ambiguous with no precedent in the grammar; bitand/bitor/bitxor read unambiguously and match MATLAB's own naming for the same idea. | and & themselves are now a clear parse error pointing here (qu-syntax::add_expr) instead of the | runtime error they used to produce.

From the note above this builtin in the interpreter, where the reasoning was written down as it was built.