Disclaimer: this post is an English translation of my original article, first published at z0rr0.blog/unsigned-integers.

Why Do We Need Them?

This is a short discussion about unsigned integers in programming. From a mathematical point of view, they may look a bit strange - why do we even need such “truncated” numbers?

Nevertheless, there are solid reasons for their existence. Here are the main ones:

1. Extending the available numeric range using the same number of bits. You can store more values if negative numbers are not required. For example, an 8-bit signed integer can store values from −128 to 127, while an unsigned type can store values from 0 to 255.

2. Additional control over business logic. Sometimes application requirements explicitly forbid negative values (for example, quantity of goods, customer age, file size, etc.). Using unsigned types helps to clearly express these constraints and prevents errors related to improper use of negative numbers.

3. Performance optimizations. On some CPU architectures, operations on unsigned numbers may be faster than on signed ones. Additionally, this serves as a hint for the compiler or interpreter that certain optimizations are possible.

How Do They Work?

Let’s write a few small examples to clearly see how unsigned integers behave.

Here is an example in Go. The program iterates over values from 0 to 259 and prints their representation as signed and unsigned numbers, along with their binary and hexadecimal forms.

package main

import (
    "fmt"
    "unsafe"
)

func s2u(s int8) uint8 {
    return *(*uint8)(unsafe.Pointer(&s))
}

func main() {
    var (
        signed   int8
        unsigned uint8
    )

    size := unsafe.Sizeof(signed)
    fmt.Printf("Size of int8 and uint8: %d byte(s)\n\n", size)

    println("+---------------------------------------------------------------------------------+")
    println("|                    Compare signed and unsigned numbers                          |")
    println("+-----+----------+----------+-----+--------+-----------+-----+--------------------+")
    println("| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |")
    println("|-----|----------|----------|-----|--------|-----------|-----|--------------------|")

    for i := range 260 {
        signed = int8(i)
        unsigned = uint8(i)
        signedAsUnsigned := s2u(signed)

        fmt.Printf("| %-3[1]d | %-8[2]d | %-8[2]b | %-3[2]x | %-6[3]d | %-9[3]b | %-3[3]x | %-18[4]b |\n", i, unsigned, signed, signedAsUnsigned)
    }

    println("+-----+----------+----------+-----+--------+-----------+-----+--------------------+")
}

The output looks like this (heavily truncated for readability, with ... inserted):

Size of int8 and uint8: 1 byte(s)

+---------------------------------------------------------------------------------+
|                    Compare signed and unsigned numbers                          |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+
| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |
|-----|----------|----------|-----|--------|-----------|-----|--------------------|
| 0   | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 1   | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 2   | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
...
| 126 | 126      | 1111110  | 7e  | 126    | 1111110   | 7e  | 1111110            |
| 127 | 127      | 1111111  | 7f  | 127    | 1111111   | 7f  | 1111111            |
| 128 | 128      | 10000000 | 80  | -128   | -10000000 | -80 | 10000000           |
| 129 | 129      | 10000001 | 81  | -127   | -1111111  | -7f | 10000001           |
| 130 | 130      | 10000010 | 82  | -126   | -1111110  | -7e | 10000010           |
...
| 254 | 254      | 11111110 | fe  | -2     | -10       | -2  | 11111110           |
| 255 | 255      | 11111111 | ff  | -1     | -1        | -1  | 11111111           |
| 256 | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 257 | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 258 | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
| 259 | 3        | 11       | 3   | 3      | 11        | 3   | 11                 |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+

And here is a similar example in Rust:

fn main() {
    let size = std::mem::size_of::<u8>();
    println!("Size of i8 and u8: {} byte(s)\n", size);

    println!("+---------------------------------------------------------------------------------+");
    println!("|                    Compare signed and unsigned numbers                          |");
    println!("+-----+----------+----------+-----+--------+-----------+-----+--------------------+");
    println!("| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |");
    println!("|-----|----------|----------|-----|--------|-----------|-----|--------------------|");

    for number in 0..260 {
        // cast 32 bit integer to 8 bit one
        let unsigned: u8 = number as u8; // unsigned integer 8 bit
        let signed: i8 = unsigned as i8; // signed integer 8 bit
        let s2u: u8 = signed as u8; // cast signed to unsigned

        println!(
            "| {0:<3} | {1:<8} | {1:<8b} | {1:<3x} | {2:<6} | {2:<9b} | {2:<3x} | {3:<18b} |",
            number, unsigned, signed, s2u,
        );
    }

    println!("+-----+----------+----------+-----+--------+-----------+-----+--------------------+");
}

The output is very similar, but with a few differences:

• In Rust, negative numbers are printed without a minus sign in binary and hexadecimal representations.

• In Go, the same values are printed using two’s complement with a leading minus sign.

It is important to understand that this is only a difference in representation. In memory, both languages store exactly the same data, and Rust also uses two’s complement internally.

Size of i8 and u8: 1 byte(s)

+---------------------------------------------------------------------------------+
|                    Compare signed and unsigned numbers                          |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+
| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |
|-----|----------|----------|-----|--------|-----------|-----|--------------------|
| 0   | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 1   | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 2   | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
...
| 126 | 126      | 1111110  | 7e  | 126    | 1111110   | 7e  | 1111110            |
| 127 | 127      | 1111111  | 7f  | 127    | 1111111   | 7f  | 1111111            |
| 128 | 128      | 10000000 | 80  | -128   | 10000000  | 80  | 10000000           |
| 129 | 129      | 10000001 | 81  | -127   | 10000001  | 81  | 10000001           |
| 130 | 130      | 10000010 | 82  | -126   | 10000010  | 82  | 10000010           |
...
| 254 | 254      | 11111110 | fe  | -2     | 11111110  | fe  | 11111110           |
| 255 | 255      | 11111111 | ff  | -1     | 11111111  | ff  | 11111111           |
| 256 | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 257 | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 258 | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
| 259 | 3        | 11       | 3   | 3      | 11        | 3   | 11                 |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+

A Short Digression on Two’s Complement. In a very simplified form, the algorithm for obtaining two’s complement (using -2 as an example) can be described as follows:

• As shown in the Rust output, the binary representation of -2 is 11111110.

• The most significant bit (the leftmost one) represents the sign: 0 for positive, 1 for negative.

• If the most significant bit is 0, the two’s complement representation is identical to the direct binary representation.

• Otherwise, to obtain the two’s complement of a negative number, invert all bits except the most significant one, resulting in 10000001, and then add 1, producing 10000010. The first bit is interpreted as the sign, and the remaining bits (0000010) represent the value 2. The final result is -2.

Looking at the outputs above, two natural questions arise:

1. How can the same binary representation be interpreted differently by the computer?

2. How do we correctly convert signed values to unsigned ones and vice versa?

For the first question, the answer is simple: there is no difference in memory. During compilation or interpretation, the analyzer tracks which type is used at each point. Depending on that type, the same sequence of bits is interpreted differently. Type information effectively lives in the program’s “metadata”, not in the data itself.

Consider this Go program program.go:

package main

func signedLess(a, b int8) bool {
    return a < b
}

func unsignedLess(a, b uint8) bool {
    return a < b
}

func main() {
    var (
        signedA   int8  = -1
        signedB   int8  = 2
        unsignedA uint8 = 255
        unsignedB uint8 = 2
    )

    println(signedLess(signedA, signedB))
    println(unsignedLess(unsignedA, unsignedB))
}

If we inspect its ARM64 assembly output:

# GOARCH=arm64
go tool compile -S program.go

main.signedLess STEXT size=32 args=0x8 locals=0x0 funcid=0x0 align=0x0 leaf
  0x0000 00000 (program.go:3)       TEXT    main.signedLess(SB), LEAF|NOFRAME|ABIInternal, $0-8
  0x0000 00000 (program.go:3)       FUNCDATA        $0, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $1, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $5, main.signedLess.arginfo1(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $6, main.signedLess.argliveinfo(SB)
  0x0000 00000 (program.go:3)       PCDATA  $3, $1
  0x0000 00000 (program.go:4)       MOVB    R0, R2
  0x0004 00004 (program.go:4)       MOVB    R1, R1
  0x0008 00008 (program.go:4)       CMPW    R2, R1
  0x000c 00012 (program.go:4)       CSET    GT, R0
  0x0010 00016 (program.go:4)       RET     (R30)
  0x0000 02 1c 40 93 21 1c 40 93 3f 00 02 6b e0 d7 9f 9a  ..@.!.@.?..k....
  0x0010 c0 03 5f d6 00 00 00 00 00 00 00 00 00 00 00 00  .._.............
main.unsignedLess STEXT size=32 args=0x8 locals=0x0 funcid=0x0 align=0x0 leaf
  0x0000 00000 (program.go:7)       TEXT    main.unsignedLess(SB), LEAF|NOFRAME|ABIInternal, $0-8
  0x0000 00000 (program.go:7)       FUNCDATA        $0, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $1, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $5, main.unsignedLess.arginfo1(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $6, main.unsignedLess.argliveinfo(SB)
  0x0000 00000 (program.go:7)       PCDATA  $3, $1
  0x0000 00000 (program.go:8)       MOVBU   R0, R2
  0x0004 00004 (program.go:8)       MOVBU   R1, R1
  0x0008 00008 (program.go:8)       CMPW    R2, R1
  0x000c 00012 (program.go:8)       CSET    HI, R0
  0x0010 00016 (program.go:8)       RET     (R30)
  0x0000 02 1c 40 d3 21 1c 40 d3 3f 00 02 6b e0 97 9f 9a  ..@.!.@.?..k....
  0x0010 c0 03 5f d6 00 00 00 00 00 00 00 00 00 00 00 00  .._.............

As shown above, even though signedA and unsignedA are stored identically in memory, the load instructions (MOVB vs MOVBU) and the condition codes used to produce the result (CSET GT vs CSET HI) are different. This is because the compiler knows which type is used in each function and emits machine code appropriate for operating on that type. The CMPW R2, R1 instruction sets condition flags based on the most significant bit, which may be interpreted as a sign bit or as part of the magnitude depending on the comparison that follows. The comparison itself is selected based on the type: GT (greater than) is used for signed comparisons, while HI (higher) is used for unsigned comparisons.

Some languages are strict about signedness. Go and Rust do not allow implicit conversions between signed and unsigned integers, which is why the examples used unsafe.Pointer in Go and as casts in Rust.

var unsigned uint8 = -1
// cannot use -1 (untyped int constant) as uint8 value in assignment (overflows)

Even in Go, mistakes are possible. For example, this code produces an infinite loop:

package main

func main() {
    var i uint

    // ...
    for i = 5; i >= 0; i-- {
        println(i)
    }
}

This is why the Google C++ Style Guide and the designers of Java were historically skeptical about using unsigned integers for arithmetic, recommending them mainly for bit masks.

In C and C++, implicit conversions are allowed and often happen without warnings:

uint8_t unsigned_number = -1; // implicit conversion, value becomes 255

A classic example is comparing signed and unsigned values, such as if (-1 > unsigned_number), which may unexpectedly evaluate to true.

Java historically had no unsigned primitives (except char, which is 16-bit), as the language designers considered them too error-prone.

Python goes even further: it has a single int type with arbitrary precision. When interpreting raw bytes, you must explicitly specify whether the value is signed or unsigned:

number = b"\xff"
unsigned = int.from_bytes(number, byteorder="big", signed=False) # 255
signed = int.from_bytes(number, byteorder="big", signed=True)  # -1

Now let us move on to the second question: how to correctly convert a signed integer to an unsigned one and vice versa. In modern programming languages, this is typically done using two’s complement representation, which we discussed earlier — for example, the value 254 (binary 11111110) is interpreted as -2. In fact, no inverse algorithm is required here: we simply reinterpret the same sequence of bits, treating the most significant bit as part of the value rather than as an explicit - / + sign.

Another way to reason about two’s complement is the following:

1. If the number is non-negative, the signed and unsigned representations are identical.

2. If the number is negative, the most significant bit is 1, and the value can be computed as 254 − 256 = −2, where 256 is 2^8, i.e. the maximum representable value for an 8-bit number plus one.

Can We Look at Another Example?

I would like to share a few examples where incorrect handling of unsigned integers has led to bugs.

Consider a ClickHouse table:

CREATE TABLE test
(
    timestamp DateTime,
    sign      Int8 DEFAULT 1,
    value     UInt8,
    comment   String
) ENGINE = MergeTree() ORDER BY timestamp;

This table stores append-only events. Logical deletions are represented by sign = -1, while value is stored as UInt8.

Now we aggregate by day using a materialized view:

CREATE MATERIALIZED VIEW mv_test
(
    `day`   Date,
    `total` UInt64
)
ENGINE = SummingMergeTree() ORDER BY day
AS
SELECT toStartOfDay(timestamp) AS day,
       sum(value * sign)       AS total
FROM test
GROUP BY day;

We choose the UInt64 type for total because we expect it to store the sum of UInt8 value events; rollbacks should evaluate to 0 and therefore not affect the final result.

INSERT INTO test
VALUES ('2026-01-01 00:00:01', 1, 1, 'number 1'),
       ('2026-01-01 00:00:02', 1, 2, 'number 2'),
       ('2026-01-01 00:00:06', 1, 255, 'number 255, max unsigned 8-bit');

SELECT * FROM mv_test ORDER BY day FORMAT Vertical;

Row 1:
──────
day:   2026-01-01
total: 258

Everything appears to work correctly, but only while implicitly assuming that rollback timestamps always совпiding with the original events. Once this assumption is broken, either by mistake or by design — issues start to surface. For example, the "2nd event rollback" record falls on the day after the "2nd event":

INSERT INTO test
VALUES ('2026-01-02 23:59:55', 1, 1, '1st event'),
       ('2026-01-02 23:59:58', -1, 1, '1st event rollback'),
       ('2026-01-02 23:59:59', 1, 1, '2nd event'),
       ('2026-01-03 00:00:02', -1, 1, '2nd event rollback');

SELECT * FROM mv_test ORDER BY day FORMAT Vertical;

Row 1:
──────
day:   2026-01-01
total: 258

Row 2:
──────
day:   2026-01-02
total: 1

Row 3:
──────
day:   2026-01-03
total: 18446744073709551615

However, a query equivalent to the materialized view mv_test produces a different result:

SELECT toStartOfDay(timestamp) AS day,
       sum(value * sign)       AS total
FROM test
GROUP BY day
ORDER BY day
FORMAT Vertical;

Row 1:
──────
day:   2026-01-01 00:00:00
total: 258

Row 2:
──────
day:   2026-01-02 00:00:00
total: 1

Row 3:
──────
day:   2026-01-03 00:00:00
total: -1

The value 18446744073709551615 is the maximum representable value of UInt64, i.e. 2^64 − 1, which corresponds to -1 when interpreted as an unsigned number. At the same time, the second query returns the correct result of -1, because by default the database engine interprets total as a signed value.

We once encountered a very similar issue in a real production system and it involved money. At some point, the total amount of refunds for a single day unexpectedly exceeded the revenue accumulated over several years :)

However, since this is only a matter of how the result is interpreted, and the underlying bytes are physically identical, the fix can be straightforward. If the materialized view is based on a separate table, it is sufficient to change the column type using an ALTER TABLE operation. Otherwise, the materialized view must be recreated and fully repopulated.

What Conclusions Can We Draw?

1. Unsigned integers play an important role in programming, enabling efficient memory usage and self-documenting constraints.

2. Signed and unsigned integers are merely different interpretations of the same bit patterns.

3. Choosing between them requires careful consideration of language rules, implicit conversions, and edge cases.

What Else Is Worth Reading?

1. Wikipedia - Unsigned integer

2. Wikipedia - Two's complement

3. Blog posts by Julia Evans

• Unsigned Integers in C and C++

• integer overflow/underflow

• how do computers represent negative integers?

• security problems because of integer overflow

• compilers removing integer overflow checks

Зачем они нужны?

Это небольшой рассказ о беззнаковых целых числах (unsigned integers) в программировании. С математической точки зрения, это немного странная конструкция, зачем вообще нужны какие-то "урезанные" числа? Но всё-таки для этого есть причины, приведу основные из них:

1. Расширение доступного диапазона чисел на том же числе бит**. Можно хранить больше значений, если отрицательные вам не нужны. Например, 8-битный знаковый целый тип может хранить значения от -128 до 127, тогда как беззнаковый тип может хранить значения от 0 до 255.
2. Дополнительный контроль бизнес-логики. Иногда требования приложения не допускают отрицательных значений (например, количество единиц товара, возраст клиента, размер файла и т.д.). Тогда использование беззнаковых типов помогает явно выразить эти ограничения и предотвратить ошибки, связанные с неправильным использованием отрицательных чисел.
3. Оптимизация производительности. В некоторых архитектурах процессоров операции с беззнаковыми числами могут выполняться быстрее, чем со знаковыми. Кроме того, это подсказка для компилятора или интерпретатора о том, что можно использовать определённые оптимизации.

Как они работают?

Давайте напишем небольшие примеры, чтобы наглядно посмотреть как работают беззнаковые целые числа.

Пример на Go - программа берёт значения от 0 до 259 и выводит их представление в виде знаковых и беззнаковых чисел, а также их бинарное и шестнадцатеричное представление.

package main

import (
    "fmt"
    "unsafe"
)

func s2u(s int8) uint8 {
    return *(*uint8)(unsafe.Pointer(&s))
}

func main() {
    var (
        signed   int8
        unsigned uint8
    )

    size := unsafe.Sizeof(signed)
    fmt.Printf("Size of int8 and uint8: %d byte(s)\n\n", size)

    println("+---------------------------------------------------------------------------------+")
    println("|                    Compare signed and unsigned numbers                          |")
    println("+-----+----------+----------+-----+--------+-----------+-----+--------------------+")
    println("| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |")
    println("|-----|----------|----------|-----|--------|-----------|-----|--------------------|")

    for i := range 260 {
        signed = int8(i)
        unsigned = uint8(i)
        signedAsUnsigned := s2u(signed)

        fmt.Printf("| %-3[1]d | %-8[2]d | %-8[2]b | %-3[2]x | %-6[3]d | %-9[3]b | %-3[3]x | %-18[4]b |\n", i, unsigned, signed, signedAsUnsigned)
    }

    println("+-----+----------+----------+-----+--------+-----------+-----+--------------------+")
}

Вывод будет следующим (я немерено сократил его для наглядности, вставив в удалённые места ...):

Size of int8 and uint8: 1 byte(s)

+---------------------------------------------------------------------------------+
|                    Compare signed and unsigned numbers                          |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+
| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |
|-----|----------|----------|-----|--------|-----------|-----|--------------------|
| 0   | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 1   | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 2   | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
...
| 126 | 126      | 1111110  | 7e  | 126    | 1111110   | 7e  | 1111110            |
| 127 | 127      | 1111111  | 7f  | 127    | 1111111   | 7f  | 1111111            |
| 128 | 128      | 10000000 | 80  | -128   | -10000000 | -80 | 10000000           |
| 129 | 129      | 10000001 | 81  | -127   | -1111111  | -7f | 10000001           |
| 130 | 130      | 10000010 | 82  | -126   | -1111110  | -7e | 10000010           |
...
| 254 | 254      | 11111110 | fe  | -2     | -10       | -2  | 11111110           |
| 255 | 255      | 11111111 | ff  | -1     | -1        | -1  | 11111111           |
| 256 | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 257 | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 258 | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
| 259 | 3        | 11       | 3   | 3      | 11        | 3   | 11                 |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+

И аналогичный пример на Rust:

fn main() {
    let size = std::mem::size_of::<u8>();
    println!("Size of i8 and u8: {} byte(s)\n", size);

    println!("+---------------------------------------------------------------------------------+");
    println!("|                    Compare signed and unsigned numbers                          |");
    println!("+-----+----------+----------+-----+--------+-----------+-----+--------------------+");
    println!("| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |");
    println!("|-----|----------|----------|-----|--------|-----------|-----|--------------------|");

    for number in 0..260 {
        // cast 32 bit integer to 8 bit one
        let unsigned: u8 = number as u8; // unsigned integer 8 bit
        let signed: i8 = unsigned as i8; // signed integer 8 bit
        let s2u: u8 = signed as u8; // cast signed to unsigned

        println!(
            "| {0:<3} | {1:<8} | {1:<8b} | {1:<3x} | {2:<6} | {2:<9b} | {2:<3x} | {3:<18b} |",
            number, unsigned, signed, s2u,
        );
    }

    println!("+-----+----------+----------+-----+--------+-----------+-----+--------------------+");
}

Вывод очень похож, но:

• В Rust у отрицательных чисел в бинарном и шестнадцатеричном представлении не выводится знак минус.
• В Go для таких же чисел используется дополнительный код с выводом знака минус.

Но важно понимать, что это отличие лишь в представлении. В памяти оба языка хранят одни и те же данные, и в Rust тоже используется дополнительный код.

Size of i8 and u8: 1 byte(s)

+---------------------------------------------------------------------------------+
|                    Compare signed and unsigned numbers                          |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+
| #   | unsigned |   bin    | hex | signed |    bin    | hex | signed as unsigned |
|-----|----------|----------|-----|--------|-----------|-----|--------------------|
| 0   | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 1   | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 2   | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
...
| 126 | 126      | 1111110  | 7e  | 126    | 1111110   | 7e  | 1111110            |
| 127 | 127      | 1111111  | 7f  | 127    | 1111111   | 7f  | 1111111            |
| 128 | 128      | 10000000 | 80  | -128   | 10000000  | 80  | 10000000           |
| 129 | 129      | 10000001 | 81  | -127   | 10000001  | 81  | 10000001           |
| 130 | 130      | 10000010 | 82  | -126   | 10000010  | 82  | 10000010           |
...
| 254 | 254      | 11111110 | fe  | -2     | 11111110  | fe  | 11111110           |
| 255 | 255      | 11111111 | ff  | -1     | 11111111  | ff  | 11111111           |
| 256 | 0        | 0        | 0   | 0      | 0         | 0   | 0                  |
| 257 | 1        | 1        | 1   | 1      | 1         | 1   | 1                  |
| 258 | 2        | 10       | 2   | 2      | 10        | 2   | 10                 |
| 259 | 3        | 11       | 3   | 3      | 11        | 3   | 11                 |
+-----+----------+----------+-----+--------+-----------+-----+--------------------+

Нужно сделать небольшое отступление о дополнительном коде. В очень упрощенном варианте алгоритм его получения можно описать так (на примере числа -2):

• Как мы видим для программы на Rust, бинарное представление -2 это 11111110.
• Старший разряд (самая левая цифра) отвечает за знак числа: 0 - положительное, 1 - отрицательное число.
• Если старший разряд равен 0, то дополнительный код совпадает с прямым бинарным представлением числа.
• Иначе, чтобы получить дополнительный код отрицательного числа, нужно инвертировать все разряды, кроме старшего, получаем 10000001 и прибавить 1, это будет 10000010. Первый бит интерпретируется как знак, а остальные 0000010 это уже само число 2. В итоге получаем -2.

Вернёмся к выводам программ, глядя на них, возникают 2 вопроса:

1. Как при одном и том же бинарном представлении одно и то же значение может интерпретироваться компьютером по-разному? Ведь в памяти это идентичные наборы нулей и единиц.
2. Как правильно рассчитать знакое значение из беззнакового и наоборот?

Попробуем ответить на 1-й вопрос. Действительно разницы нет, но при компиляции или интерпретации кода, анализатор программы помечает какой тип используется в конкретном месте, в зависимости от этого, набор нулей и единиц выводится по-разному. По сути, информация о типе хранится в условных "метаданных" программы, а не в самих этих данных.

Рассмотрим на примере Go ассемблера такую программу program.go:

package main

func signedLess(a, b int8) bool {
    return a < b
}

func unsignedLess(a, b uint8) bool {
    return a < b
}

func main() {
    var (
        signedA   int8  = -1
        signedB   int8  = 2
        unsignedA uint8 = 255
        unsignedB uint8 = 2
    )

    println(signedLess(signedA, signedB))
    println(unsignedLess(unsignedA, unsignedB))
}

А затем посмотрим на ее ассемблерный вывод:

# GOARCH=arm64
go tool compile -S program.go

main.signedLess STEXT size=32 args=0x8 locals=0x0 funcid=0x0 align=0x0 leaf
  0x0000 00000 (program.go:3)       TEXT    main.signedLess(SB), LEAF|NOFRAME|ABIInternal, $0-8
  0x0000 00000 (program.go:3)       FUNCDATA        $0, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $1, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $5, main.signedLess.arginfo1(SB)
  0x0000 00000 (program.go:3)       FUNCDATA        $6, main.signedLess.argliveinfo(SB)
  0x0000 00000 (program.go:3)       PCDATA  $3, $1
  0x0000 00000 (program.go:4)       MOVB    R0, R2
  0x0004 00004 (program.go:4)       MOVB    R1, R1
  0x0008 00008 (program.go:4)       CMPW    R2, R1
  0x000c 00012 (program.go:4)       CSET    GT, R0
  0x0010 00016 (program.go:4)       RET     (R30)
  0x0000 02 1c 40 93 21 1c 40 93 3f 00 02 6b e0 d7 9f 9a  ..@.!.@.?..k....
  0x0010 c0 03 5f d6 00 00 00 00 00 00 00 00 00 00 00 00  .._.............
main.unsignedLess STEXT size=32 args=0x8 locals=0x0 funcid=0x0 align=0x0 leaf
  0x0000 00000 (program.go:7)       TEXT    main.unsignedLess(SB), LEAF|NOFRAME|ABIInternal, $0-8
  0x0000 00000 (program.go:7)       FUNCDATA        $0, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $1, gclocals·g5+hNtRBP6YXNjfog7aZjQ==(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $5, main.unsignedLess.arginfo1(SB)
  0x0000 00000 (program.go:7)       FUNCDATA        $6, main.unsignedLess.argliveinfo(SB)
  0x0000 00000 (program.go:7)       PCDATA  $3, $1
  0x0000 00000 (program.go:8)       MOVBU   R0, R2
  0x0004 00004 (program.go:8)       MOVBU   R1, R1
  0x0008 00008 (program.go:8)       CMPW    R2, R1
  0x000c 00012 (program.go:8)       CSET    HI, R0
  0x0010 00016 (program.go:8)       RET     (R30)
  0x0000 02 1c 40 d3 21 1c 40 d3 3f 00 02 6b e0 97 9f 9a  ..@.!.@.?..k....
  0x0010 c0 03 5f d6 00 00 00 00 00 00 00 00 00 00 00 00  .._.............

Как видно выше, несмотря на то, что signedA и unsignedA в памяти хранятся одинаково, операции загрузки данных MOVB / MOVU и установки результата CSET GT / CSET HI различаются. Это происходит потому, что компилятор знает, какой тип используется в каждой функции, и генерирует соответствующий машинный код для выполнения операций с этими типами. Сравнение CMPW R2, R1 будет считать числа отрицательными или положительными в зависимости от старшего бита. Сама операция сравнения тоже выбирается в зависимости от типа: для знаковых чисел используется GT (greater than), а для беззнаковых HI (higher).

Некоторые языки относятся строго к типизации со знаком или без. Например, Go или Rust не даст вам неявно преобразовать знаковое число в беззнаковое и наоборот. Именно поэтому в программах выше использовался вызов с unsafe.Pointer для Go и as для Rust, чтобы явно указать на необходимость изменения типа:

var unsigned uint8 = -1
// cannot use -1 (untyped int constant) as uint8 value in assignment (overflows)

Но и в Go можно допустить ошибку, например, получить бесконечный цикл можно так:

package main

func main() {
    var i uint

    // ...
    for i = 5; i >= 0; i-- {
        println(i)
    }
}

Именно поэтому, например, Google C++ Style Guide и создатели Java (изначально) скептически относились к unsigned типам для арифметики, рекомендуя их только для битовых масок.

А например, в C или C++ неявное преобразование возможно, причём без предупреждений компилятора, что часто приводит к сложно детектируемым ошибкам:

uint8_t unsigned_number = -1; // неявное преобразование, будет равно 255

Ещё классический пример - это сравнение знакового и беззнакового числа if (-1 > unsigned_number), когда можно неожиданно получить true, так как -1 будет интерпретировано как большое беззнаковое число.

В Java долгое время вообще не было беззнаковых примитивов (кроме char, который 16-битный), потому что создатели языка считали, что это слишком сложно для программистов.

В Python всё ещё более свободно, там нет отдельных типов для знаковых и беззнаковых чисел, есть только int, который может принимать любые значения в пределах доступной памяти. Но как мы уже узнали выше, если данные для представления не отличаются, то как быть, когда нужно из байт всё-таки получить число, ведь оно может быть разным? Для это требуется явно указать, какой тип мы ожидаем получить:

number = b"\xff"
unsigned = int.from_bytes(number, byteorder="big", signed=False) # беззнаковое целое 255
signed = int.from_bytes(number, byteorder="big", signed=True)  # знаковое целое -1

Теперь перейдём ко 2-му вопросу, как правильно преобразовать знаковое число в беззнаковое и наоборот. В современных языках обычно используется дополнительный код, о котором мы писали выше, когда 254 (бинарное 11111110) становится -2. Обратный алгоритм тут кстати не нужен, мы просто интерпретируем набор нулей и единиц как есть, учитывая старший бит как часть числа, а не знак - / +.

Ещё один способ посчитать дополнительный код:

1. Если число положительное, то беззнаковое и знаковое представление совпадают
2. Если число отрицательное, старший бит равен 1, тогда 254 - 256 = -2, где 256 это 2^8, то есть максимально возможное значение для 8-битного числа плюс 1.

Можно ещё один пример?

Хочется поделиться примерами, когда неправильная работа с беззаковыми числами привела к ошибкам.

Пусть у нас есть Clickhouse база данных с таблицей вида:

CREATE TABLE test
(
    timestamp DateTime,
    sign      Int8 DEFAULT 1,
    value     UInt8,
    comment   String
) ENGINE = MergeTree() ORDER BY timestamp;

Это какие-то события во времени, а так как данные append-only, то есть мы их только добавляем, то для отмены (условное удаление) используется признак sign, который может быть 1 или -1, а само значение value хранится в беззнаковом типе UInt8.

Теперь нам хочется агрегировать события по дням и мы создаем materialized view:

CREATE MATERIALIZED VIEW mv_test
(
    `day`   Date,
    `total` UInt64
)
ENGINE = SummingMergeTree() ORDER BY day
AS
SELECT toStartOfDay(timestamp) AS day,
       sum(value * sign)       AS total
FROM test
GROUP BY day;

Для total мы выбираем тип UInt64, так как ожидаем, что это сумма событий value Uint8, отмены при этом должны нам дать 0 и не влияют на итоговый результат.

INSERT INTO test
VALUES ('2026-01-01 00:00:01', 1, 1, 'number 1'),
       ('2026-01-01 00:00:02', 1, 2, 'number 2'),
       ('2026-01-01 00:00:06', 1, 255, 'number 255, max unsigned 8-bit');

SELECT * FROM mv_test ORDER BY day FORMAT Vertical;

Row 1:
──────
day:   2026-01-01
total: 258

Вроде бы всё хорошо, но лишь до того момента, пока мы не забыли или специально решили, что время отмены не совпадает со временем основного события. Например, запись для '2nd event rollback' попала на следующим день после '2nd event':

INSERT INTO test
VALUES ('2026-01-02 23:59:55', 1, 1, '1st event'),
       ('2026-01-02 23:59:58', -1, 1, '1st event rollback'),
       ('2026-01-02 23:59:59', 1, 1, '2nd event'),
       ('2026-01-03 00:00:02', -1, 1, '2nd event rollback');

SELECT * FROM mv_test ORDER BY day FORMAT Vertical;

Row 1:
──────
day:   2026-01-01
total: 258

Row 2:
──────
day:   2026-01-02
total: 1

Row 3:
──────
day:   2026-01-03
total: 18446744073709551615

Но запрос аналогичный MV mv_test показывает другой результат:

SELECT toStartOfDay(timestamp) AS day,
       sum(value * sign)       AS total
FROM test
GROUP BY day
ORDER BY day
FORMAT Vertical;

Row 1:
──────
day:   2026-01-01 00:00:00
total: 258

Row 2:
──────
day:   2026-01-02 00:00:00
total: 1

Row 3:
──────
day:   2026-01-03 00:00:00
total: -1

Значение 18446744073709551615 это максимально возможное значение для UInt64 = 2^64 - 1, то есть -1, интерпретированное как беззнаковое число. При этом 2-й запрос показывает правильный результат -1, так как по умолчанию СУБД интерпретирует total как знаковое число.

Похожую проблему мы поймали когда-то в реальном проекте, причём это касалось денег, неожиданно сумма возвратов за день превысила выручку за несколько лет :)

Но так как это лишь интерпретация вывода данных, а физически байты идентичны, то если MV создано на основе отдельной таблицы, достаточно изменить тип колонки через операцию ALTER TABLE. Иначе придётся пересоздавать MV заново и перезаполнять его.

Какие выводы можно сделать?

1. Беззнаковые числа играют важную роль в программировании, позволяя эффективно использовать память и самодокументировать логику программ.
2. Важно понимать, что беззнаковые и знаковые числа это просто разные способы интерпретации одного и того же набора бит.
3. Нужно быть предельно аккуратными при выборе подобного типа данных, понимая ограничения используемого языка и то, как он делает преобразования между типами.

Что ещё почитать?

1. Wikipedia - Unsigned integer
2. Wikipedia - Two's complement
3. Примеры из блога Julia Evans
   • Unsigned Integers in C and C++
   • integer overflow/underflow
   • how do computers represent negative integers?
   • security problems because of integer overflow
   • compilers removing integer overflow checks

Итераторы и генераторы

В определении на сайте doc.python.org говорится, что объект-итератор должен

• Содержать метод __next__(), вызываем встроенным методом next() для возвращения следующего элемента коллекции.
• Если данных больше нет, то должно возникать исключение StopIteration.
• Также обязателен метод __iter__() для возвращения объекта-итератора.

Примеры встроенных типов, примеров итераторов это list, tuple.

С генераторами тоже все довольно просто. Это объекты, возвращающие функцию генерации с выражением yield. Её особенность в том, что при следующем вызове, функция продолжает свою работу не с самого начала, а с места использования этого служебного слова.

from typing import Generator
def generator(start: int, stop: int, step: int = 1) -> Generator[int, None, None]:
    """
    Генератор целых чисел от start до stop с шагом step.

    >>> list(generator(5, 13, 2))
    [5, 7, 9, 11, 13]
    """
    i = start
    while i <= stop:
        yield i
        i += step

Особенно хочется подчеркнуть, что существуют удобные выражения-генераторы, когда отдельная функция не нужна.

Классы

Посмотрим на примеры классов, которые являются итераторами. Например в стандартной библиотеке есть пакет csv, создав объект reader, можно итерироваться непосредственно по нему:

import csv
csv_file = open('my_file.csv')
my_reader = csv.reader(csv_file)
for row in my_reader:
    print(row)

Кроме того в данном примере файл не парсится весь сразу, а данные возвращаются по ходу его чтения. Это уже поведения генератора.

Попытается написать класс с похожим поведением.

Простой генератор

Пример класса, который может выступать генератором, возвращающим квадраты чисел из входного списка.

class SquareIterator:
    """
    R квадратов чисел.

    >>> s = SquareIterator([3, 5, 7])
    >>> list(s)
    [9, 25, 49]
    >>> list(s)
    []
    """

    def __init__(self, data: List[int]) -> None:
        self.index = 0
        self.total = len(data)
        self.data = data

    def __iter__(self) -> Iterator[int]:
        return self

    def __next__(self) -> int:
        if self.index >= self.total:
            raise StopIteration
        value = self.data[self.index] ** 2
        self.index += 1
        return value

Но иногда хочется иметь возможность итерироваться по коллекции несколько раз, как например мы можем это делать по типу list. Для этого нужно дополнить метод __iter__ сбросом начального состояния.

class SquareInfIterator(SquareIterator):
    """
    Генератор квадратов чисел с возможностью повторного вызова.

    >>> s = SquareIterator([3, 5, 7])
    >>> list(s)
    [9, 25, 49]
    >>> list(s)
    [9б 25 49]
    """

    def __iter__(self) -> Iterator[int]:
        self.index = 0
        return self

Произвольный генератор

Метод __iter__ не обязан всегда возвращать self. В качестве возвращаемого значения ожидается любой генератор, который потом можно использовать в качестве аргумента для next():

class RangeGenerator:
    """
    Range генератор.

    >>> r = RangeGenerator(5, 13, 2)
    >>> list(r)
    [5, 7, 9, 11, 13]
    """

    def __init__(self, start: int, stop: int, step: int = 1) -> None:
        self.start = start
        self.stop = stop
        self.step = step

    def __iter__(self) -> Generator[int, None, None]:
        i = self.start
        while i <= self.stop:
            yield i
            i += self.step

Аналогичным образом можно написать генератор, похожий на csv.reader, когда не нужно читать файл целиком и нам интересны операции на отдельными строками:

class FileLineLenGenerator:
    """
    Генератор длин строк файла.

    >>> f = FileLineLenGenerator('my_file.txt')
    >>> list(f)
    [4, 3, 8]
    """
    def __init__(self, file_name: str) -> None:
        self.file_name = file_name

    def __iter__(self) -> Generator[int, None, None]:
        with open(self.file_name) as f:
            for line in f:
                yield len(line)

Заключение

Python итераторы это очень мощный инструмент языка. С помощью генераторов можно совершать "ленивые" вычисления, экономив на памяти. А возможность создавать произвольные классы итераторы делает программирование более гибким.

Все примеры доступны на github.com.

Disclaimer

This is not an example for production code.
It is bad practice to move patterns from known programming language to new one. But sometimes you can adapt them.

Many programming languages have a special type of collection called generator. It’s lazy structure, that works with one item in one time. So it is more efficiency by memory but you can iterate by objects only once.

Python example

def gen(start: int, stop: int, step: int) -> Generator[int, None, None]:
    x = start
    while x < stop:
        yield x
        x += step

g = gen(5, 20, 3)
print(g)
# <generator object gen at 0x104c85f20>

print(list(g))
# [5, 8, 11, 14, 17]

# second call returns empty list
# because there is no history of returned data
print(list(g))
# []

Go language doesn't have generators in the standard library. Let’s write three different implementation of this pattern and compare them.

Channel generator

Go channel is a nice mechanism for concurrency communication. One goroutine sends (generates) data to a channel and reader receives the value. Every time we work only with one item.

import "fmt"

// ErrOffsetIteration is error for failed step/size value.
var ErrOffsetIteration = errors.New("iteration offset must be positive")

// ChanGenerator is a range generator.
func ChanGenerator(start, stop, step int) (chan int, error) {
    if step < 1 {
        return nil, ErrOffsetIteration
    }
    c := make(chan int)
    go func() {
        for j := start; j < stop; j += step {
            c <- j
        }
        close(c)
    }()
    return c, nil
}

// how to use it (without error check)
g, _ := ChanGenerator(5, 20, 3)
for j := range g {
    fmt.Println(j)
}

Many consumers can safety read generator’s data from a channel, but it should be slowly due to internal locks, we will check this later.

Function generator

The second implementation is a function with closure. We create initial state i and modify it inside an internal returned anonymous function.

import (
    "sync"
    "fmt"
)

// ErrStopIteration is error when iteration is finished.
var ErrStopIteration = errors.New("stop iteration")

// FuncGenerator is a function closure int generator.
func FuncGenerator(start, stop, step int) func() (int, error) {
    if step < 1 {
        return func() (int, error) {
            return 0, ErrOffsetIteration
        }
    }
    var m sync.Mutex
    i := start
    return func() (int, error) {
        m.Lock()
        defer func() {
            i += step
            m.Unlock()
        }()
        if i >= stop {
            step = 0
            return 0, ErrStopIteration
        }
        return i, nil
    }
}

// how to use it
var (
    j   int
    err error
)
g := FuncGenerator(5, 20, 3)
for j, err = g(); err == nil; j, err = g() {
    fmt.Println(j)
}
if err != ErrStopIteration {
    fmt.Println("oops")
    // handle error
}

Mutex is required here, because concurrent function calls can update i in several goroutines.

Struct generator

The latest generator example is structure. It has a current value and stores additional parameters. Also our structure must have mutex like an example before, because concurrent reading should be safety.

// StructGenerator is a struct generator.
type StructGenerator struct {
    sync.Mutex
    stop  int
    step  int
    value int
}

// NewStructGenerator returns a new struct generator.
func NewStructGenerator(start, stop, step int) (*StructGenerator, error) {
    if step < 1 {
        return nil, ErrOffsetIteration
    }
    return &StructGenerator{stop: stop, step: step, value: start}, nil
}

// Next returns a new generation value and flag that it is not the end.
func (g *StructGenerator) Next() (int, bool) {
    defer func() {
        g.Lock()
        g.value += g.step
        g.Unlock()
    }()
    return g.value, g.value < g.stop
}

// how to use it (without error handling)
g, _ := NewStructGenerator(5, 20, 3)
for v, ok := g.Next(); ok; v, ok = g.Next() {
    fmt.Println(v)
}

It’s very easy way, it’s interesting to compare all three methods by speed and memory usage.

Benchmarks

I wrote simple example using Go benchmark mechanism testing.B and got results:

goos: darwin
goarch: amd64
pkg: github.com/z0rr0/blog/posts/go-generators/example
cpu: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
BenchmarkChanGenerator-8         5772 205862 ns/op 145 B/op 2 allocs/op
BenchmarkFuncGenerator-8        66204  17777 ns/op  72 B/op 4 allocs/op
BenchmarkStructGenerator_Next-8 65004  18028 ns/op  64 B/op 1 allocs/op

The histograms show results more clearly

And comparing by memory usage

Conclusion

There are different ways to implement generators in Go. Using channels is not the best idea. Of course we need to control concurrent access, but standard mutex can do it better.

I also wrote examples for chunk generators then we need to split a slice into pieces. For example, we want to convert [1, 2, 3,… 10] to 5 chunks by 2 items [1, 2], [3, 4], … [9, 10]. The same ways were used for it. You can find it in repo go-generators/example

# create list of odd numbers with cycle
a = []
for i in range(10):
    if i % 2:
        a.append(i)

# create same collection using list comprehension
a = [i for i in range(10) if i % 2]

It isn’t only syntax sugar, comprehensions have CPython code optimisations and work faster. But what benefits do they provide? Let’s try to evaluate this.

I wrote a simple python program to compare execution for operation create collections using cycles and comprehensions. We will check dict, list and set. Base class for benchmarking has methods

from typing import Dict, List, Set

class BaseBench:

    def __init__(self, n: int = 1) -> None:
        self.n = n

    def get_new_dict(self) -> Dict[int, str]:
        raise NotImplementedError

    def get_filtered_dict(self, data: Dict[int, str]) -> Dict[int, str]:
        raise NotImplementedError

    def get_new_set(self) -> Set[int]:
        raise NotImplementedError

    def get_filtered_set(self, data: Set[int]) -> Set[int]:
        raise NotImplementedError

    def get_new_list(self) -> List[int]:
        raise NotImplementedError

    def get_filtered_list(self, data: List[int]) -> List[int]:
        raise NotImplementedError

I write here a part of code, example only for dict. Other listings you can find in github:

class CycleBench(BaseBench):

    def get_new_dict(self) -> Dict[int, str]:
        result = {}
        for i in range(self.n):
            if i % 2:
                result[i] = 'odd'
            else:
                result[i] = 'even'
        return result

    def get_filtered_dict(self, data: Dict[int, str]) -> Dict[int, str]:
        result = {}
        for key, value in data.items():
            if key % 2:
                result[key] = value
        return result


class ComprehensionBench(BaseBench):

    def get_new_dict(self) -> Dict[int, str]:
        return {i: 'odd' if i % 2 else 'even' for i in range(self.n)}

    def get_filtered_dict(self, data: Dict[int, str]) -> Dict[int, str]:
        return {key: value for key, value in data.items() if key % 2}

It’s interesting to check comprehension efficiency with different sizes of collections, small [10-1000] and big [10k-100k].

We see that more efficiency of comprehension is for list, and there is minimal time difference for dict.

Conclusion

Yes, comprehension is faster and often does code more readable. But it is not a rule «always use comprehension». For some cases cycles are better. For example sometimes maintainability may be more important than performance.