DEV Community: Alexandre

XOR — Backpropagation na prática em rust

Alexandre — Mon, 13 Jul 2026 14:32:46 +0000

No post anterior construímos uma rede MLP completa com forward pass e backpropagation. A rede funcionava. Neste post vamos atacar algo que um único neurônio nunca consegue resolver, o XOR, e entender por que isso exige uma rede com camada oculta.

Conteúdo

1 Prólogo
2 O problema XOR
3 Por que um neurônio não resolve
4 A estrutura da rede
5 Forward pass — avançando pela rede
6 Loss — medindo o erro com BCE
7 Backpropagation — o gradiente voltando
8 Resultados
9 Conclusão

1. Prólogo

O problema do canhão que escolhemos nos posts anteriores não era o mais adequado para representar o potencial da nossa implementação. Como ele deixava muitos "vazios" entre os exemplos do dataset, dificilmente conseguiríamos chegar ao resultado exato sem adicionar mais complexidade ao modelo.

Por isso, para colocar nossa implementação de backpropagation em prática e observar um resultado mais concreto e satisfatório, vamos implementar uma solução para o XOR.

O XOR é um problema clássico usado para validar implementações de backpropagation. Ele é simples o suficiente para entendermos cada etapa do treinamento manualmente, mas complexo o bastante para exigir uma camada oculta. Historicamente, esse problema ficou famoso por mostrar as limitações dos perceptrons de camada única, contribuindo para o declínio das pesquisas na área após a publicação do livro de Minsky e Papert, em 1969.

2. O problema XOR

XOR (exclusive OR) retorna 1 quando as entradas são diferentes e 0 quando são iguais:

A | B | A XOR B
0 | 0 |    0
0 | 1 |    1
1 | 0 |    1
1 | 1 |    0

Plotando os 4 pontos num plano 2D, onde a cor indica a classe, o problema fica visível:

Os zeros ficam nas diagonais opostas aos uns. Não existe nenhuma linha reta que separe as duas classes.

Para contrastar, o AND é linearmente separável onde uma única reta isola o único ponto verdadeiro (1,1):

Linearmente separável significa que existe uma reta que divide perfeitamente as classes. XOR não é. AND é.

Matematicamente: não existe nenhum conjunto de pesos e bias capaz de representar o XOR usando apenas uma transformação linear.

3. Por que um neurônio não resolve

Um único neurônio calcula y = sigmoid(Wx + b), é uma transformação linear seguida de uma função de ativação sempre criando uma reta.

Com um único neurônio só conseguimos desenhar retas, e retas não resolvem XOR. Com múltiplos neurônios em camadas, cada um aprende uma transformação diferente do espaço, e essa transformações cria as curvas necessárias para separar o que uma reta nunca conseguiria.

A camada oculta não tenta separar diretamente, ela aprende uma nova forma de representar os pontos, transformando o espaço de entrada em algo onde a separação se torna possível.

É como dobrar um papel antes de cortar, com papel aberto, o corte não resolve. Dobrado, um único corte separa tudo. A camada oculta faz essa dobra e a camada de saída faz o corte.

4. A estrutura da rede

Para resolver XOR precisamos de uma rede com duas camadas:

entrada (2)  →  camada oculta (4)  →  saída (1)

2 entradas — os bits A e B
4 neurônios ocultos — cada um aprende uma "dobra" diferente do espaço. XOR precisa de no mínimo 2, usamos 4 para dar mais folga ao gradiente encontrar uma solução
1 saída — um único valor entre 0 e 1. Para um par como [0, 1], após passar pelas transformações da camada oculta, a rede produz a probabilidade de a saída ser 1. Valores próximos de 0 significam "provavelmente 0", próximos de 1 significam "provavelmente 1"

Em Rust, representamos isso como uma struct com dois conjuntos de pesos e bias, um por camada:

pub struct Network {
    pub w1: Matrix,   // shape: 2×4 — pesos da camada oculta
    pub b1: Vec<f64>, // shape: 4   — bias da camada oculta
    pub w2: Matrix,   // shape: 4×1 — pesos da camada de saída
    pub b2: f64,      //             — bias da camada de saída
}

w1 tem shape 2×4 porque conecta 2 entradas a 4 neurônios. w2 tem shape 4×1 porque combina os 4 neurônios ocultos em 1 saída.

Os pesos são inicializados aleatoriamente e o treino vai ajustar. Os bias começam em zero:

impl Network {
    pub fn new() -> Self {
        let mut rng = rand::thread_rng();
        Network {
            w1: Matrix::new(2, 4, (0..8).map(|_| rng.gen_range(-1.0..1.0)).collect()),
            b1: vec![0.0; 4],
            w2: Matrix::new(4, 1, (0..4).map(|_| rng.gen_range(-1.0..1.0)).collect()),
            b2: 0.0,
        }
    }
}

5. Forward pass — avançando pela rede

Com a estrutura definida, podemos alimentar a rede com o dataset. Ao entrar com um par [A, B], ele percorre a rede camada por camada até virar uma previsão.

O mesmo y = Wx + b do primeiro neurônio, agora aplicado duas vezes em sequência com x sendo um vetor e W uma matriz:

y = sigmoid(sigmoid([A, B] @ W1 + b1) @ W2 + b2)

O fluxo completo:

[A, B]  →  X @ W1 + b1  →  sigmoid  →  X @ W2 + b2  →  sigmoid  →  saída

Função de ativação — sigmoid

Sem uma função de ativação entre as camadas, empilhar y = Wx + b duas vezes ainda resulta numa reta. A ativação é o que quebra essa linearidade.

Usamos o sigmoid:

σ(x) = 1 / (1 + e^(-x))

Ela espreme qualquer valor real para o intervalo (0, 1), o que faz sentido para o nosso problema onde a saída final é uma probabilidade.

fn sigmoid(x: f64) -> f64 {
    1.0 / (1.0 + (-x).exp())
}

Outra propriedade que vai ser útil no backprop: a derivada do sigmoid tem forma simples, σ(x) * (1 - σ(x)), facilitando os gradientes.

Implementando o forward

O forward é passar o input pelas duas camadas em sequência. Usamos z para a parte linear (antes do sigmoid) e a para o resultado após a ativação, essa convenção vai aparecer de novo no backprop:

pub fn forward(&self, x: &Matrix) -> Vec<f64> {
    // Fórmula completa: y = sigmoid(sigmoid(x @ W1 + b1) @ W2 + b2)

    // ── Camada oculta ─────────────────────────────────────────────
    let z1 = x.matmul(&self.w1); // z1 = x @ W1  (linear, sem ativação ainda)

    let mut a1_data = vec![0.0; x.rows * 4];
    for i in 0..x.rows {
        for j in 0..4 {
            a1_data[i * 4 + j] = sigmoid(z1.get(i, j) + self.b1[j]); // a1 = sigmoid(z1 + b1)
        }
    }
    let a1 = Matrix::new(x.rows, 4, a1_data); // a1 é o espaço transformado

    // ── Camada de saída ───────────────────────────────────────────
    let z2 = a1.matmul(&self.w2); // z2 = a1 @ W2  (linear)

    (0..x.rows).map(|i| sigmoid(z2.get(i, 0) + self.b2)).collect() // a2 = sigmoid(z2 + b2)
}

a1 é a saída da camada oculta, os 4 neurônios já transformados pelo sigmoid. É ela que entra na camada de saída, não o input original. O diagrama abaixo mostra o forward do par [A=0, B=1] com os valores reais em cada nó:

A rede ainda não sabe nada, os pesos são aleatórios e a previsão é ruído. O que vem a seguir é o que transforma esse ruído em conhecimento.

6. Loss — medindo o erro com BCE

O forward produz uma previsão ŷ. Para saber o quanto a rede errou, precisamos de uma função que compare ŷ com o valor esperado y e retorne um número, quanto maior, pior a previsão. Esse número é a loss.

Usamos Binary Cross-Entropy (BCE), que é a loss correta para classificação binária, quando a saída é uma probabilidade entre 0 e 1:

L = -1/n * Σ [ y * log(ŷ) + (1-y) * log(1-ŷ) ]

A intuição: quando y=1 e ŷ é próximo de 0, log(ŷ) vira um número muito negativo e a loss explode. Quando ŷ é próximo de 1, log(ŷ) se aproxima de 0 e a loss some. A função pune previsões confiantes e erradas com muito mais força do que o MSE faria.

pub fn bce(predictions: &[f64], targets: &[f64]) -> f64 {
    let n = predictions.len() as f64;
    predictions.iter().zip(targets.iter()).map(|(&yhat, &y)| {
        let yhat = yhat.clamp(1e-7, 1.0 - 1e-7); // evita log(0)
        -(y * yhat.ln() + (1.0 - y) * (1.0 - yhat).ln())
    }).sum::<f64>() / n
}

O clamp evita log(0) que seria -∞. Na prática a rede nunca prevê exatamente 0 ou 1, mas é uma proteção necessária.

Para o backprop precisamos também da derivada da loss em relação a ŷ:

dL/dŷ = -y/ŷ + (1-y)/(1-ŷ)

pub fn bce_grad(predictions: &[f64], targets: &[f64]) -> Vec<f64> {
    let n = predictions.len() as f64;
    predictions.iter().zip(targets.iter()).map(|(&yhat, &y)| {
        let yhat = yhat.clamp(1e-7, 1.0 - 1e-7);
        (-y / yhat + (1.0 - y) / (1.0 - yhat)) / n
    }).collect()
}

Esse gradiente é o ponto de partida do backprop, o erro medido na saída que vai voltar camada por camada até ajustar cada peso da rede.

7. Backpropagation — o gradiente voltando

Com a loss calculada, precisamos saber quanto cada peso contribuiu para o erro e em qual direção ajustár. Isso é o backprop: aplicar a chain rule de trás pra frente, camada por camada.

O fluxo inverso ao forward:

dL/dŷ  →  dL/dz2  →  dL/dW2, dL/db2
                  →  dL/da1  →  dL/dz1  →  dL/dW1, dL/db1

1. Gradiente da loss → dL/dŷ

Vem direto do bce_grad, um valor por exemplo do dataset.

2. Desfazendo o sigmoid da saída → dL/dz2

O sigmoid foi a última operação antes de ŷ. Para voltar por ele usamos sua derivada, σ'(x) = σ(x) * (1 - σ(x)):

dz2[i] = dl_dyhat[i] * yhat[i] * (1.0 - yhat[i]);

3. Gradientes de W2 e b2

z2 = a1 @ W2 + b2, então:

// dW2 = a1ᵀ @ dz2
for k in 0..4 {
    for i in 0..batch {
        dw2[k] += a1.get(i, k) * dz2[i];
    }
}
let db2: f64 = dz2.iter().sum();

4. Propagando para a camada oculta → dL/dz1

O gradiente chega em a1 via W2, depois passa pelo sigmoid da camada oculta:

for i in 0..batch {
    for k in 0..4 {
        let dl_da1 = dz2[i] * self.w2.get(k, 0); // ← volta por W2
        let a = a1.get(i, k);
        dz1[i][k] = dl_da1 * a * (1.0 - a);      // ← desfaz sigmoid
    }
}

5. Gradientes de W1 e b1

Mesmo padrão da camada anterior:

let dw1 = x.transpose().matmul(&dz1); // dW1 = Xᵀ @ dz1
// db1[k] = Σ dz1 por coluna

6. Update — gradient descent

Com os gradientes calculados, ajustamos cada peso na direção que reduz a loss:

// w = w - lr * dw
for i in 0..self.w1.data.len() { self.w1.data[i] -= lr * dw1.data[i]; }
for k in 0..4 { self.b1[k] -= lr * db1[k]; }
for k in 0..4 { self.w2.data[k] -= lr * dw2[k]; }
self.b2 -= lr * db2;

Repetir isso para cada epoch, forward → loss → backward → update, é o treino completo.

O diagrama abaixo mostra os gradientes voltando pela rede. A espessura de cada aresta representa a magnitude do gradiente naquele peso:

8. Resultados

Rodamos o treino por 20.000 epochs com lr = 0.5. Antes do treino os pesos são aleatórios e as 4 previsões ficam em torno de 0.5. Depois, cada previsão converge exatamente para o valor correto:

Dá para ver a rede aprendendo epoch por epoch. No epoch 0 tudo é ruído, no epoch 500 já começa a separar os zeros, no epoch 2000 quase lá, a partir do epoch 5000 os pontos grudam nos targets. A cor indo de roxo para verde segue o progresso:

A curva de loss começa em ~0.69 (máximo da BCE com pesos aleatórios) e cai até ~0.0007:

Resultado final:

[0 XOR 0] → 0.0008  classe: 0  esperado: 0  ✓
[0 XOR 1] → 0.9993  classe: 1  esperado: 1  ✓
[1 XOR 0] → 0.9993  classe: 1  esperado: 1  ✓
[1 XOR 1] → 0.0007  classe: 0  esperado: 0  ✓

4/4. O backprop está funcionando.

9. Conclusão

Neste post implementamos uma rede neural que resolve o XOR do zero, com forward pass, BCE e backpropagation completo em Rust.

O que foi aprendido:

Separabilidade linear — um único neurônio só desenha retas. XOR precisa de curvas, o que exige uma camada oculta
Sigmoid como ativação — transforma qualquer valor real em probabilidade (0,1) e tem derivada simples que facilita o backprop
BCE — a loss correta para classificação binária, pune previsões confiantes e erradas com muito mais força do que o MSE
Backpropagation — a chain rule aplicada de trás pra frente, desfazendo cada operação do forward para calcular o gradiente de cada peso
Gradient descent — w = w - lr * dw, repetido epoch por epoch até a loss convergir

O que ainda não resolvemos: o dataset XOR tem só 4 pontos e a rede decorou a solução. Para problemas reais, com dados mais distribuidos e distribuições desconhecidas, precisamos de generalização, regularização e validação. Isso fica para frente.

Referências

Se este post fizer sentido pra você, o próximo passo natural é representar conceitos como vetores em vez de números, e ver como a semântica emerge da geometria desse espaço.

Backpropagation: treinando uma rede neural em Rust

Alexandre — Thu, 09 Jul 2026 14:24:03 +0000

No post anterior construímos o forward pass completo com duas camadas e ativação podendo já gerar uma previsão, mas os pesos eram aleatórios e nunca mudavam. Neste post fechamos o loop: loss, backpropagation e gradient descent.

Conteúdo

1 Prólogo
2 A rede prevê mas não aprende
3 Medindo o erro com MSE
4 O gradiente da saída
5 Backpropagation
6 Atualizando os pesos
7 O loop de treino
8 Conclusão

1. Prólogo

Nos ultimos posts trabalhamos na estrutura para implementar o Backpropagation que eu estava tão animado pois é um dos algoritmos mais famosos nesse ambiente de ML. Conseguimos já compreender como trabalhar com matrizes para termos camadas na rede e o papel da funcao de ativacao nesse processo mas ainda não implementamos o fluxo de treinamento, então vamos nessa, sem medo de ser feliz !

2. A rede prevê mas não aprende

Os pesos W e b foram inicializados aleatórios e nunca mudavam com isso a rede gerava uma pervisão mas não aprendia o caminho para melhorar.

Para aprender essas três coisas precisam acontecer em sequência:

Medir o erro: o quanto a previsão se afastou do valor real - MSE
Calcular os gradientes: em qual direção ajustar cada peso para reduzir esse erro - Gradient descent
Atualizar os pesos: aplicar o ajuste em cada camada

No nosso contexto de treinamento com multiplas Layers precisamos fazer de uma forma diferente de como fazermos com somente 1 neuronio esses processo.

3. Medindo o erro com MSE

A fórmula é a mesma que já conhecemos:

MSE = (1/n) × Σ (previsão - target)²

A diferença é que previsão agora é uma Matrix (n×1), uma linha por exemplo do batch:

pub fn mse(predictions: &Matrix, targets: &[f64]) -> f64 {
    let n = targets.len() as f64;
    let sum: f64 = (0..targets.len())
        .map(|i| {
            let diff = predictions.get(i, 0) - targets[i];
            diff * diff
        })
        .sum();
    sum / n
}

Com os nossos 2 exemplos antes de qualquer treino:

previsões: [6.66, 5.30]
targets:   [60.0, 80.0]

erro[0] = (6.66  - 60.0)² = 2840.7
erro[1] = (5.30  - 80.0)² = 5580.5

MSE = (2840.7 + 5580.5) / 2 = 4210.6

Loss alto é esperado e os pesos ainda são aleatórios então o nosso objetivo é fazer esse número cair.

4. O gradiente da saída

O MSE nos dá 1 número para monitora o treino, mas para ajustar os pesos precisamos de algo mais específico: o quanto cada previsão individualmente precisa mudar, e em qual direção.

Isso vem da derivada do MSE em relação à saída da última camada.

No nosso caso ∂MSE/∂z2 com 2 layers a última saída é z2 que é o resultado de a1 @ W2 + b2, sem aplicar nenhuma ativação. Essa saída bruta é a previsão final da rede

A camada de saída não tem ReLU porque a rede precisa poder prever qualquer número: com ReLU ela nunca preveria valores negativos.

O gradiente dessa saída é

∂MSE/∂z2 = (2/n) × (z2 - target)

O resultado é uma matriz (n×1), um valor por exemplo:

z2      = [ 0.527]     targets = [60.0]
          [-1.011]               [80.0]

∂L/∂z2 = (2/2) × (z2 - targets)
        = [-59.473]
          [-81.011]

Cada valor diz quanto e em qual direção a previsão precisa mudar que é o papel do gradient descent. É o sinal que inicia o backpropagation.

O MSE monitora. O gradiente do MSE guia.

pub fn mse_grad(predictions: &Matrix, targets: &[f64]) -> Matrix {
    let n = targets.len() as f64;
    let data: Vec<f64> = (0..targets.len())
        .map(|i| (2.0 / n) * (predictions.get(i, 0) - targets[i]))
        .collect();
    Matrix::new(targets.len(), 1, data)
}

5. Backpropagation

Backpropagation calcula os gradientes, quanto cada peso contribuiu para o erro. Quem usa esses gradientes para ajustar os pesos é o gradient descent, que vem depois. São dois papéis separados que acontecem em sequência.

O forward que é o primeiro treino iniciado com valores aleatorios, precisa guardar os valores intermediários porque o backprop vai percorrer o mesmo caminho ao contrário:

forward:  guarda →  z1, a1, z2  (previsão com os pesos atuais)
backprop: usa    ←  z2, a1, z1  (percorre de trás pra frente)

O fluxo completo de gradientes por camada:

∂L/∂z2                        ← gradiente da saída (mse_grad)
∂L/∂W2 = a1.T @ ∂L/∂z2       ← gradiente de W2
∂L/∂b2 = soma(∂L/∂z2)         ← gradiente de b2
∂L/∂a1 = ∂L/∂z2 @ W2.T       ← propaga pela Layer2 (transposta)
∂L/∂z1 = ∂L/∂a1 × relu'(z1)  ← propaga pelo ReLU
∂L/∂W1 = input.T @ ∂L/∂z1    ← gradiente de W1
∂L/∂b1 = soma(∂L/∂z1)         ← gradiente de b1

A transposta aparece em dois lugares e vale explicar o porquê.

No forward, a multiplicação foi a1 @ W2: a1 tem formato (n × 4) e W2 tem formato (4 × 1). Para calcular o gradiente de W2, precisamos de uma operação que resulte em (4 × 1), o mesmo formato de W2. Fazendo a1.T @ ∂L/∂z2, ou seja (4 × n) @ (n × 1), chegamos exatamente em (4 × 1). A transposta é o que acerta os formatos para a multiplicação funcionar na direção inversa.

O mesmo raciocínio vale para propagar o sinal de volta para a camada 1: no forward foi ∂L/∂z2 @ W2, então no backward é ∂L/∂z2 @ W2.T para os formatos baterem e o sinal chegar em a1 com o formato certo.

O relu_grad zera o gradiente onde z1 era negativo, porque o neurônio estava desligado no forward e não contribuiu para o erro:

pub fn backward(input: &Matrix, z1: &Matrix, a1: &Matrix, w2: &Matrix, grad_z2: &Matrix) -> Gradients {
    let grad_w2 = a1.transpose().matmul(grad_z2);
    let grad_b2 = col_sum(grad_z2);

    let grad_a1 = grad_z2.matmul(&w2.transpose());
    let grad_z1 = relu_grad(&grad_a1, z1);  // zera onde z1 era negativo

    let grad_w1 = input.transpose().matmul(&grad_z1);
    let grad_b1 = col_sum(&grad_z1);

    Gradients { grad_w1, grad_b1, grad_w2, grad_b2 }
}

Neurônio desligado no forward não recebe ajuste no backward.

6. Atualizando os pesos

Com os gradientes calculados, o update é simples: andar na direção oposta ao gradiente, em todas as camadas, elemento a elemento.

W = W - lr × ∂L/∂W
b = b - lr × ∂L/∂b

// Layer 2
for i in 0..camada2.w.rows {
    for j in 0..camada2.w.cols {
        let grad = grads.grad_w2.get(i, j);
        camada2.w.set(i, j, camada2.w.get(i, j) - lr * grad);
    }
}
for j in 0..camada2.b.len() {
    camada2.b[j] -= lr * grads.grad_b2[j];
}

// Layer 1
for i in 0..camada1.w.rows {
    for j in 0..camada1.w.cols {
        let grad = grads.grad_w1.get(i, j);
        camada1.w.set(i, j, camada1.w.get(i, j) - lr * grad);
    }
}
for j in 0..camada1.b.len() {
    camada1.b[j] -= lr * grads.grad_b1[j];
}

O sinal de menos é o que faz o peso andar na direção que reduz o loss. O lr (learning rate) controla o tamanho do passo.

7. O loop de treino

Agora o loop fecha de verdade. Os valores abaixo são da epoch 0, antes de qualquer ajuste:

O loop completo por epoch:

for epoch in 0..epochs {
    // 1. forward
    let z1 = camada1.forward(&dataset.inputs);
    let a1 = relu(&z1);
    let z2 = camada2.forward(&a1);

    // 2. loss
    let loss = mse(&z2, &dataset.targets);

    // 3. backprop
    let grad_z2 = mse_grad(&z2, &dataset.targets);
    let grads = backward(&dataset.inputs, &z1, &a1, &camada2.w, &grad_z2);

    // 4. update
    // ... atualiza W2, b2, W1, b1
}

Repete por N epochs. A cada iteração os pesos se aproximam dos valores que minimizam o loss.

O que o gráfico mostra

0–50 epochs: queda brusca, os pesos saem do aleatório e encontram uma direção clara. O gradiente é grande porque o erro é enorme, os passos são grandes.

50–300 epochs: oscilações, a rede está refinando mas ainda não encontrou um caminho estável. O gradiente varia bastante de epoch para epoch porque os exemplos puxam os pesos em direções ligeiramente diferentes.

300–1000 epochs: estabilização, as oscilações somem e o loss converge suavemente. Com mais exemplos o gradiente vira uma média de mais pontos a cada epoch, o que suaviza o sinal e permite uma descida mais consistente.

O erro cai de ~54 e ~75 para ~4 e ~4

8. Conclusão

Bbackprop e gradient descent são coisas diferentes que trabalham juntas. Backprop percorre a rede de trás pra frente calculando quanto cada peso contribuiu pro erro. Gradient descent usa esse resultado para dar um passo na direção certa. A separação faz sentido porque o mesmo gradiente poderia ser usado por estratégias de update diferentes.

Uma limitação que fica clara ao olhar o backward.rs: cada linha foi calculada à mão para essa arquitetura específica de 2 camadas com ReLU no meio.

// essas fórmulas foram derivadas para: input → Layer1 → ReLU → Layer2 → saída
let grad_w2 = a1.transpose().matmul(grad_z2);
let grad_a1 = grad_z2.matmul(&w2.transpose());
let grad_z1 = relu_grad(&grad_a1, z1);
let grad_w1 = input.transpose().matmul(&grad_z1);

Se quiséssemos adicionar uma terceira camada, ou trocar o ReLU por uma função de ativação diferente, precisaríamos abrir o backward.rs, derivar os gradientes para a nova arquitetura e reescrever as fórmulas. A estrutura não é reutilizável.

O Micrograd do Karpathy resolve isso de outra forma, em vez de calcular as derivadas uma vez para uma arquitetura fixa, cada operação (+, *, @) traz regra de como calcular seu próprio gradiente. No forward, a rede monta um grafo de operações. No backward, percorre esse grafo automaticamente, aplicando cada regra em sequência, independente de quantas camadas ou funções de ativação existam.

O resultado é o mesmo, os gradientes corretos para cada peso. A diferença é que não é mais preciso escrever backward.rs na mão para cada arquitetura que se queira testar.

Resolver isso pode ser o projeto seguinte autograd.

Referências

Se este post fizer sentido pra você, o próximo passo é eliminar a necessidade de escrever backprop à mão para cada arquitetura, construindo um sistema de autograd.

Por que camadas lineares sozinhas não funcionam e o que a ReLU resolve

Alexandre — Mon, 06 Jul 2026 17:34:12 +0000

No post anterior montamos o forward pass com duas camadas lineares em sequência. A rede parece ter mais "profundidade" mas matematicamente ela não tem. Neste post vamos entender por que e o que a função de ativação resolve.

Conteúdo

1 Prólogo
2 O colapso linear
3 O que é uma função de ativação
4 ReLU no gráfico
5 ReLU no código
6 Onde a ativação entra — e onde não entra
7 Conclusão

1. Prólogo

Já montamos o forward pass na nossa layer com duas camadas lineares em sequência

let z1 = camada1.forward(&dataset.inputs); // X @ W1 + b1
let z2 = camada2.forward(&z1);             // z1 @ W2 + b2

Parece que a rede tem mais "profundidade" agora mas matematicamente estamos apenas empilhando camadas lineares sem ganho real para o aprendizado. As coisas pareciam conceitualmente simples, mas precisamos de um pouco mais de teoria para chegar num resultado melhor. Não se desespere como eu fiz: mesmo que esses conceitos não fiquem totalmente claros de primeira, acredito que consegui chegar numa explicação que melhora bastante a intuição sobre o assunto.

2. O colapso linear

Depois de construir a Layer, a ideia natural é empilhar várias, uma camada processa a entrada e passa para a próxima, que refina o resultado.

O problema é que duas camadas lineares em sequência sempre colapsam numa única camada linear.

Suponha 2 inputs e duas camadas de pesos.

X = [10.0, 80.0]

W1 = [
 [ 0.5, -0.4]
 [ 0.2, -0.1]
]

b1 = [1.0, 2.0]

Na camada 1 aplicando o forward chegamos em Z = X @ W1 + b1

z1 = 10×0.5  + 80×0.2  + 1 =  22
z2 = 10×(-0.4) + 80×(-0.1) + 2 = -10

Z = [22, -10]

Agora passamos Z para a camada 2.

W2 = [
 [0.4, 0.2]
 [0.6, 0.1]
]

b2 = [0.5, 1.0]

Aplicando novamente o forward:

Y = Z @ W2 + b2

y1 = 22×0.4 + (-10)×0.6 + 0.5 = 3.3
y2 = 22×0.2 + (-10)×0.1 + 1.0 = 4.4

Y = [3.3, 4.4]

Apesar de termos usado duas camadas tudo isso ainda é equivalente a uma única transformação linear(Y = X @ W + b)

X
 ↓
Layer(2,2)
 ↓
Layer(2,2)
 ↓
Y

OU para 1 unico neurônio que é o método `y = x * w + b;`

z = x * w1 + b1;
y = z * w2 + b2;

É como se o treinamento tivesse aprendido um único conjunto de pesos equivalente ao efeito combinado dos dois.

Isso acontece porque multiplicações e somas são operações lineares.

Se colocarmos uma ativação no meio:

X
 ↓
Linear
 ↓
ReLU
 ↓
Linear
 ↓
Y

OU

z = x*w1 + b1
a = ReLU(z)
y = a*w2 + b2

O ponto principal é que não existe mais um único w e b que reproduzam exatamente esse comportamento para todos os valores de x.

Por isso costumamos dizer:

Sem ativação, várias camadas são apenas uma regressão linear disfarçada.
Com ativação, a rede passa a representar funções muito mais complexas.

3. O que é uma função de ativação

Uma função de ativação é aplicada elemento a elemento à saída de uma camada antes de passar para a próxima.

O papel dela é introduzir não-linearidade, um comportamento que nenhuma combinação de pesos e bias consegue reproduzir.

A mais simples é a ReLU:

ReLU(x) = max(0, x)

Ela zera os negativos e deixa os positivos passarem:

entrada: [-3.0,  2.0, -0.5,  1.8]
saída:   [ 0.0,  2.0,  0.0,  1.8]

Por que zerar negativos remove a linearidade?

Uma função é linear se f(a + b) = f(a) + f(b). Testando com ReLU:

ReLU(-1) + ReLU(1) = 0 + 1 = 1
ReLU(-1 + 1) = ReLU(0) = 0

1 ≠ 0

A propriedade não vale. O "zerar" cria um comportamento assimétrico onde positivos passam, negativos não e isso quebra o que permite o colapso.

Voltando ao exemplo do tópico anterior e agora com ReLU entre as camadas:

Z = [22, -10]   ← saída da camada 1

ReLU([22, -10]) = [22, 0]   ← o -10 foi zerado

Y = [22, 0] @ W2 + b2

y1 = 22×0.4 + 0×0.6 + 0.5 = 9.3
y2 = 22×0.2 + 0×0.1 + 1.0 = 5.4

Y = [9.3, 5.4]

Sem ReLU o resultado era [3.3, 4.4]. Com ReLU é [9.3, 5.4]. O neurônio 2 foi zerado no meio do caminho — e agora não existe nenhum W e b que, numa única camada, produza [9.3, 5.4] para esse input e ao mesmo tempo se comporte diferente para outros inputs onde o neurônio 2 não seria zerado. O comportamento depende do sinal dos valores intermediários, e isso quebra o colapso.

4. ReLU no gráfico

A forma mais direta de entender o que a ativação faz é olhando o gráfico de duas redes com a mesma arquitetura (1 → 4 → 1) e os mesmos pesos — a única diferença é a ReLU entre as camadas.

À esquerda: linha reta, sempre — independente de quantas layers.

À direita: segmentos retos com dobras. Cada neurônio oculto contribui com um ponto de dobra onde seu valor pré-ativação cruza zero. Com 4 neurônios ocultos, até 4 dobras possíveis.

Essas dobras são o que permite à rede aproximar padrões complexos que uma linha reta nunca conseguiria representar.

5. ReLU no código

A implementação em Rust é trivial:

pub fn relu(input: &Matrix) -> Matrix {
    let data: Vec<f64> = (0..input.rows)
        .flat_map(|i| (0..input.cols).map(move |j| (i, j)))
        .map(|(i, j)| input.get(i, j).max(0.0))
        .collect();

    Matrix::new(input.rows, input.cols, data)
}

Recebe uma Matrix, devolve uma Matrix do mesmo formato com os negativos zerados. O pipeline fica:

let z1 = camada1.forward(&input); // X @ W1 + b1
let a1 = relu(&z1);               // zera os negativos
let z2 = camada2.forward(&a1);    // a1 @ W2 + b2

6. Onde a ativação entra — e onde não entra

A ativação é aplicada depois do forward de cada camada oculta. A camada de saída não leva ativação.

input
  ↓
Layer 1 → forward → ReLU   ← camadas ocultas levam ativação
  ↓
Layer 2 → forward           ← saída final, sem ativação
  ↓
previsão

Se zerássemos os negativos na saída, a rede nunca conseguiria prever valores negativos o que seria um problema para qualquer tarefa de regressão.

7. Conclusão

Neste post entendemos por que empilhar camadas lineares não adiciona expressividade e como a ReLU resolve isso com uma operação simples.

O que foi construído:

A função relu
Pipeline completo: Layer1 → ReLU → Layer2
Visualização do colapso linear vs ReLU no gráfico

No próximo post: backpropagation como medir o erro e fazer a rede aprender de verdade.

Referências

Se este post fizer sentido pra você, o próximo passo é ensinar a rede a aprender com os próprios erros isso vem no próximo post da série.

De um neurônio para uma rede — matrizes, camadas e o forward pass

Alexandre — Mon, 06 Jul 2026 17:10:01 +0000

Um neurônio com uma entrada só aprende uma reta. Para modelar problemas reais precisamos de mais entradas, mais neurônios e uma forma eficiente de organizar tudo isso. Neste post vamos construir em Rust as peças que tornam uma rede neural possível: matrizes, camadas e o forward pass.

Conteúdo

1 Prólogo
2 O que é uma matriz na prática
3 Multiplicação matricial — o que está acontecendo
4 O que é uma Layer
5 Forward pass
6 Conclusão

1. Prólogo

No projeto anterior tínhamos um único neurônio prevendo a distância de uma bala de canhão com um peso, uma entrada e uma saída. Simples, mas inútil para qualquer problema real.

A distância de uma bala não depende só da energia — depende do vento, do ângulo, do peso do projétil. A rede precisa aprender como cada fator influencia o resultado com um peso diferente. Quando temos múltiplas entradas, múltiplos neurônios e múltiplos exemplos ao mesmo tempo, entram as matrizes.

Antes a fórmula era distância = w × energia + b mas com múltiplas entradas (features) o modelo se expande:

distância = w₁×energia + w₂×vento + w₃×ângulo + b

Isso pode ser resumido na notação matricial:

Y = X @ W + b

O @ é multiplicação matricial. Ele faz exatamente a mesma soma ponderada de antes, mas organizada de forma que funciona para múltiplas features e múltiplos exemplos ao mesmo tempo.

2. O que é uma matriz na prática

Uma matriz é uma tabela de números organizada em linhas e colunas.

X representa o dataset de entrada onde cada linha é um exemplo e cada coluna é uma feature. Para 2 exemplos com 3 features, X tem formato (2×3):

let x = Matrix::new(2, 3, vec![
    10.0, 80.0, 0.30,   // exemplo 0: energia=10, vento=80, ângulo=0.30
    20.0, 60.0, 0.25,   // exemplo 1: energia=20, vento=60, ângulo=0.25
]);

W também vira uma matriz. Com 3 features e 2 neurônios na saída, W tem formato (3×2) onde cada coluna representa um neurônio:

let w = Matrix::new(3, 2, vec![
    0.5, 0.1,   // pesos da energia  — neurônio 1 e 2
    0.3, 0.4,   // pesos do vento    — neurônio 1 e 2
    0.2, 0.6,   // pesos do ângulo   — neurônio 1 e 2
]);

b é um Vec<f64> com um valor por neurônio. Ele não entra na multiplicação de matrizes pois é somado diretamente à saída:

let b: Vec<f64> = vec![0.2, 0.1]; // um bias por neurônio

3. Multiplicação matricial — o que está acontecendo

No projeto anterior usávamos * para multiplicar um peso por uma entrada. O @ faz a mesma conta para todas as features e todos os exemplos de uma vez.

Para o exemplo 0 com 1 neurônio:

X[0] = [10.0, 80.0, 0.3]
W    = [0.5,  0.3,  0.2]

saída[0] = 10.0×0.5 + 80.0×0.3 + 0.3×0.2
         = 5.0 + 24.0 + 0.06
         = 29.06

A implementação completa fica assim:

pub fn matmul(&self, other: &Matrix) -> Matrix {
    assert_eq!(
        self.cols, other.rows,
        "dimensões incompatíveis: {}×{} · {}×{}",
        self.rows, self.cols, other.rows, other.cols
    );

    let m = self.rows;  // linhas de X  (exemplos)
    let n = other.cols; // colunas de W (neurônios)
    let k = self.cols;  // features — devem bater com linhas de W

    let mut result = Matrix::zeros(m, n);

    for i in 0..m {         // cada exemplo
        for j in 0..n {     // cada neurônio
            let mut sum = 0.0;
            for p in 0..k { // soma ponderada das features
                sum += self.get(i, p) * other.get(p, j);
            }
            result.set(i, j, sum);
        }
    }

    result
}

O assert_eq! garante que as dimensões batem antes de rodar. Se X tem 3 colunas, W precisa ter 3 linhas pois sem isso o loop produziria resultados errados silenciosamente.

4. O que é uma Layer

Com um único neurônio: 1 peso, 1 bias, 1 saída. Ele só consegue aprender uma relação linear simples.

Uma Layer é um conjunto de neurônios operando juntos sobre a mesma entrada onde você define quantos neurônios quer e ela cria um W com uma coluna por neurônio:

pub struct Layer {
    pub w: Matrix,
    pub b: Vec<f64>,
}

// 3 features de entrada, 4 neurônios na camada
Layer::new(3, 4)

Os valores de W são inicializados aleatórios, não zeros. Se todos os pesos começassem iguais, todos os neurônios aprenderiam exatamente a mesma coisa e a camada inteira seria inútil.

A escala do aleatório também importa. Pesos muito grandes e os valores explodem ao passar pelas camadas. Muito pequenos e desaparecem. Para isso usamos Xavier initialization — o intervalo é proporcional ao número de entradas:

let scale = (1.0 / in_features as f64).sqrt(); // ≈ 0.577 para 3 features
let w_data: Vec<f64> = (0..in_features * out_features)
    .map(|_| rng.gen_range(-scale..scale))
    .collect();

Gerando pesos dentro de um intervalo controlado, como:

W (3×4):
 -0.52,  0.18, -0.31,  0.44,
  0.57, -0.12,  0.08, -0.49,
 -0.21,  0.63, -0.55,  0.37

O bias começa em zeros — ele não tem o mesmo problema de simetria que os pesos.

5. Forward pass

O forward é a função da layer que aplica Y = X @ W + b.

Com um único neurônio isso era y = x * w + b. Com vários neurônios e vários exemplos ao mesmo tempo, a mesma conta vira multiplicação matricial:

X (1 exemplo, 3 features):
  [10.0, 80.0, 0.3]

W (3 features, 4 neurônios):
  [-0.41,  0.12, -0.29,  0.33]
  [ 0.51, -0.08,  0.05, -0.44]
  [-0.19,  0.55, -0.48,  0.27]

b = [0.0, 0.0, 0.0, 0.0]

y1 = 10×(-0.41) + 80×0.51  + 0.3×(-0.19) + 0  ≈  36.64
y2 = 10×0.12   + 80×(-0.08) + 0.3×0.55   + 0  ≈  -5.04
y3 = 10×(-0.29) + 80×0.05  + 0.3×(-0.48) + 0  ≈   0.96
y4 = 10×0.33   + 80×(-0.44) + 0.3×0.27   + 0  ≈ -31.82

Y = [36.64, -5.04, 0.96, -31.82]

Cada valor de Y é a saída de um neurônio da camada. A implementação:

pub fn forward(&self, input: &Matrix) -> Matrix {
    let mut out = input.matmul(&self.w); // X @ W

    for i in 0..out.rows {
        for j in 0..out.cols {
            out.set(i, j, out.get(i, j) + self.b[j]); // + b
        }
    }

    out
}

Chamamos isso de forward pass porque a informação avança pela rede da entrada até a saída. Mais tarde, durante o treinamento, faremos o caminho inverso (backward pass) para ajustar os pesos e reduzir o erro.

6. Conclusão

Neste post saímos de um neurônio com uma entrada e chegamos numa camada com múltiplos neurônios recebendo múltiplas features ao mesmo tempo.

O que foi construído:

A struct Matrix com multiplicação matricial e validação de dimensões
A struct Layer com Xavier initialization e forward
A struct Dataset com inputs e targets
O forward pass completo com duas camadas em sequência

No próximo post: funções de ativação, backpropagation e o loop de treino que faz a rede aprender de verdade.

Referências

Se este post fizer sentido pra você, o próximo passo é adicionar ativação entre as camadas e ensinar a rede a aprender com os próprios erros e isso vem no próximo post da série.

Gradient Descent — opimizando seu neurônio em rust

Alexandre — Wed, 01 Jul 2026 16:35:42 +0000

IA do zero: Gradient Descent — otimizando seu neurônio em rust

Você já usou o GPT, mas sabe o que existe dentro dele? Neste post vamos ensinar o neurônio a melhorar suas previsões de forma inteligente usando gradient descent, o algoritmo que está por trás de praticamente todo o aprendizado de máquina moderno.

Conteúdo

1 Prólogo
2 O problema com o ±0.01
3 Medindo o erro geral — Loss (MSE)
4 A parábola — visualizando o loss
5 O gradiente — a inclinação como bússola
6 Gradient Descent — descendo a parábola
7 Implementando o Gradient Descent
8 Resultado — ±0.01 vs Gradient Descent
9 Conclusão

1. Prólogo

Retomando o post anterior, implementamos um neurônio capaz de aprender a prever a distância de um projétil com base na energia do disparo. O treinamento e os resultados foram razoáveis, mas o algoritmo de ajuste utilizado era propositalmente simples para fins educacionais.

Agora vamos entender e implementar o tão temido Gradient Descent.

Confesso que, durante meu aprendizado desse tópico, me assustei um pouco com as notações matemáticas, uso de derivadas e gráficos em três dimensões para dar um pequeno passo além do que parecia tão simples no último post. Mas, depois de estudar um pouco mais, acredito que consegui entender um pouco melhor o assunto então vou tentar compartilhar esse entendimento aqui.

2. O problema com o ±0.01

O treino anterior ajustava w e b com um passo fixo:

if error > 0.0 {
    self.weight -= 0.01;
    self.bias   -= 0.01;
} else if error < 0.0 {
    self.weight += 0.01;
    self.bias   += 0.01;
}

O problema aparece na prática:

erro = 500  → ajusta 0.01
erro = 0.5  → ajusta 0.01

Quando o neurônio está muito errado, deveria dar passos grandes e quando está quase certo, passos pequenos para não passar do ponto.

O que precisamos é de um ajuste proporcional ao erro. É aí que entra o loss e depois o gradient descent.

3. Medindo o erro geral — Loss (MSE)

Já calculamos o erro de um item no dataset de forma simples no post anterior

erro = previsto - real

Mas precisamos entender o quão errado o neurônio está no conjunto inteiro de dados, e não apenas em um exemplo específico. Se ficarmos ajustando as variáveis somente com base no erro de um par do dataset, acabamos prejudicando o resultado nos outros. Precisamos, portanto, de uma forma de calcular o erro médio sobre todo o dataset — isso é o que chamaremos de loss.

Para isso precisamos da média dos erros

loss = (erro1 + erro2 + erro3) / n

O problema é que erros se cancelam:

ponto A: erro = +30  (previu demais)
ponto B: erro = -30  (previu de menos)

média = 0  ← parece perfeito, mas está errado nos dois casos

A solução é o MSE — Mean Squared Error (Erro Quadrático Médio):

loss = (1/n) × Σ (previsto - real)²

Elevar ao quadrado tem dois efeitos:

Remove o sinal: erros positivos e negativos não se cancelam mais
Penaliza erros grandes: um erro de 10 vira 100, um erro de 2 vira 4

erro = 2  → contribuição = 4
erro = 10 → contribuição = 100

Um erro cinco vezes maior gera uma penalização vinte e cinco vezes maior, o loss deve gritar quando o neurônio está muito errado.

pub fn loss(dataset: &[(f64, f64)], neuron: &Neuron) -> f64 {
    let n = dataset.len() as f64;
    let sum: f64 = dataset
        .iter()
        .map(|(x, actual)| {
            let error = neuron.predict(*x) - actual;
            error * error
        })
        .sum();
    sum / n
}

MSE é a fórmula. Loss é o conceito. A partir daqui vamos usar o termo loss para falar do erro geral do neurônio.

4. A parábola — visualizando o loss

Agora que temos o loss, podemos calcular o loss para cada valor possível de w e plotar o resultado. Para isso, fixamos b=18 como estimativa inicial, isolando o efeito de w no gráfico.

Podemos observar que o gráfico tem formato de parábola caindo até um mínimo e sobe novamente, o ponto onde w=0.92 é o valor ideal para b=18, o mínimo do loss nesse dataset.

O objetivo do treino é encontrar os valores de w e b que reduzem ao máximo o loss.

Na prática, quando temos dois parâmetros (w e b), o loss vira uma superfície 3D — algo parecido com uma tigela. Nosso objetivo continua o mesmo: atingir o ponto mais fundo. O gradient descent faz isso descendo essa superfície simultaneamente nos dois eixos.

5. O gradiente — a inclinação como bússola

Você está em algum ponto da parábola e quer chegar no fundo, o gradiente é a inclinação da curva naquele ponto e ele te diz duas coisas:

Direção: se a curva está subindo, você vai na direção oposta
Magnitude: curva íngreme (longe do fundo) → passo grande. Quase plana (perto do fundo) → passo pequeno

w=0   → inclinação íngreme → passo grande
w=0.8 → inclinação suave  → passo pequeno
w=0.9 → fundo da parábola → gradiente = 0, para

É exatamente o que faltava no ±0.01: o passo proporcional à inclinação, não fixo.

Os gradientes do loss em relação a w e b são:

∂loss/∂w = (2 / dataset_size) * Σ(erro * x)
∂loss/∂b = (2 / dataset_size) * Σ(erro)

w multiplica por x porque w está ligado a x na equação do neurônio (y = wx + b).
b acumula apenas o erro, pois é um deslocamento constante, não depende de x.

Não precisa se assustar com essas fórmulas, pois não vamos derivá-las agora.

Por enquanto, basta entender que elas medem a inclinação do erro em relação a w e b, indicando para qual direção devemos mover os parâmetros e o quão forte deve ser essa atualização.

Na implementação, veremos que calcular os gradientes é bem mais simples do que a notação matemática sugere.

6. Gradient Descent — descendo a parábola

Agora que entendemos que precisamos alterar w e b em direção ao mínimo podemos aplicar essa fórmula

erro = previsto - real
dataset_size = dataset.len

∂L/∂w = (2 / dataset_size) * Σ(erro * x)
∂L/∂b = (2 / dataset_size) * Σ(erro)

Gradient Descent
w = w - lr * ∂loss/∂w
b = b - lr * ∂loss/∂b

Assim nasce o Gradient Descent, para aplicar vamos primeiro definir um valor de lr=0.0001, que é o tamanho do passo que vamos dar.

lr muito grande → passa do fundo, fica oscilando
lr muito pequeno → chega lá, mas demora muito
lr ideal → desce suave até o mínimo

Para aplicar vamos definir alguns valores iniciais

w  = 10.0
b  = 10.0
lr = 0.0001
dataset_size = 4

Também vamos definir um dataset

(1,  60)
(2,  80)
(10, 60)
(4,  70)

Com w=10, b=10 o neurônio calcula previsto = 10x + 10. Agora acumulamos Σ(erro) e Σ(erro * x) ponto a ponto:

posição	x	real	previsto	erro = previsto - real	erro × x
1	1	60	20	-40	-40
2	2	80	30	-50	-100
3	10	60	110	50	500
4	4	70	50	-20	-80

Calculando os somatórios Σ(erro) e Σ(erro * x)

Σ(erro * x) = -40 + -100 + 500 + -80 = 280
Σ(erro)     = -40 +  -50 +  50 + -20 = -60

Calculando as derivadas ∂L/∂w e ∂L/∂b

∂L/∂w = (2 / 4) * 280 = 140
∂L/∂b = (2 / 4) * -60 = -30

Calculando Gradient Descent

weight = 10.0 - 0.0001 * 140    → 9.986
bias   = 10.0 - 0.0001 * (-30)  → 10.003

Chegamos em um ajuste de w=10 para w=9.986 e b=10 para b=10.003. Com ∂L/∂w = +140 o gradiente é positivo, então diminuímos w, o neurônio estava prevendo demais em x=10. Com ∂L/∂b = -30 o gradiente é negativo, então aumentamos b, a maioria dos pontos estava sendo subestimada.

7. Implementando o Gradient Descent

Agora que calculamos manualmente os valores chegou a parte mais fácil que é implementar nosso algoritmo.

1. Inicializa Σ(erro * x) e Σ(erro)

let mut error_x_sum = 0.0;  // Σ(erro * x)
let mut error_sum   = 0.0;  // Σ(erro)

2. Acumula os erros do dataset

Para cada ponto calculamos o erro e acumulamos os dois somatórios.

for (x, actual) in dataset {
    let error = self.predict(*x) - actual;

    error_x_sum += error * x;
    error_sum   += error;
}

3. Calcula as derivadas ∂L/∂w e ∂L/∂b

Transformamos os somatórios nos gradientes finais dividindo pelo tamanho do dataset.

let grad_w = (2.0 / dataset_size) * error_x_sum;  // ∂L/∂w
let grad_b = (2.0 / dataset_size) * error_sum;     // ∂L/∂b

4. Aplica o Gradient Descent

Andamos na direção oposta ao gradiente (por isso o -), com passo controlado pelo lr.

grad_w positivo → diminuímos w
grad_w negativo → aumentamos w
grad_w próximo de zero → estamos perto do mínimo

self.weight -= lr * grad_w;
self.bias   -= lr * grad_b;

5. Implementação completa

pub fn train(&mut self, dataset: &[(f64, f64)], lr: f64, epochs: usize) {
    let dataset_size = dataset.len() as f64;

    for _epoch in 0..epochs {
        let mut error_x_sum = 0.0;
        let mut error_sum   = 0.0;

        for (x, actual) in dataset {
            let error = self.predict(*x) - actual;
            error_x_sum += error * x;
            error_sum   += error;
        }

        let grad_w = (2.0 / dataset_size) * error_x_sum;
        let grad_b = (2.0 / dataset_size) * error_sum;

        self.weight -= lr * grad_w;
        self.bias   -= lr * grad_b;
    }
}

8. Resultado — ±0.01 vs Gradient Descent

Rodamos os dois algoritmos com as mesmas condições iniciais:

	±0.01	Gradient Descent
Epochs	1000	1000
Passo	fixo `0.01`	proporcional ao gradiente
Learning rate	—	`0.0003`
W inicial	5.0	5.0
B inicial	5.0	5.0

Com isso obtivemos os seguintes resultados

O que o gradient descent faz é encontrar a melhor reta possível dentro dessa limitação e o loss mostra isso claramente caindo de 77 no ±0.01 para 37. No gráfico abaixo podemos observar isso

Outro ponto que vale destacar é a forma como o gradient descent realiza os ajustes de w e b, cada ponto é uma epoch. Com ±0.01 dá passos iguais o tempo todo, mesmo perto do fundo continua com a mesma força, já o gradient descent desacelera conforme se aproxima e para quando o gradiente chega a zero. No gráfico abaixo podemos observar isso

Ainda assim a linha não tocou perfeitamente todos os pontos, para isso seriam necessários mais parâmetros e mais neurônios, ou seja, uma rede neural. Isso vem nas próximas fases.

9. Conclusão

Neste post saímos de um ajuste cego e implementamos gradient descent, o algoritmo base do aprendizado de máquina moderno.

O que foi aprendido:

O loss (MSE) transforma os erros individuais num único número que representa o desempenho geral do neurônio
O gradiente é a inclinação do loss em relação a cada parâmetro e ele diz a direção e o tamanho do passo
O gradient descent desce a superfície de loss simultaneamente em w e b até encontrar o mínimo

O que ainda não resolvemos: com um único neurônio e uma função linear, o melhor que conseguimos é uma reta e dados que não seguem uma reta linear não podem ser modelados assim, independente de quantas epochs ou de qual algoritmo de treino.

No próximo post: redes neurais, múltiplos neurônios em camadas que juntos conseguem aprender padrões não-lineares.

Referências

Se este post fizer sentido pra você, o próximo passo natural é adicionar mais neurônios e introduzir funções de ativação é aí que o aprendizado começa a capturar padrões que uma reta simples não consegue descrever.

Implementar seu primeiro neurônio em Rust

Alexandre — Tue, 30 Jun 2026 22:26:20 +0000

Você já usou o GPT, mas sabe o que existe dentro dele? Neste post vamos construir em Rust o bloco mais fundamental de qualquer rede neural, um único neurônio e entender na prática como previsão, erro e treino funcionam.

Conteúdo

1 Prólogo
2 O problema
3 O que é um dataset
4 A fórmula: y = mx + b
5 Implementando o neurônio
6 Calculando o erro
7 Desenvolvendo o training loop
8 As limitações desse método
9 Conclusão

1. Prólogo

Tenho usado muita IA ultimamente para escrever código, construir produtos e acompanhar tudo o que está acontecendo na área. Um ponto com o qual sempre concordo é a importância de estudar os fundamentos.

Em algum momento usamos jQuery, depois React, Vue, Svelte, Next, Nuxt, Xupt, Xep e plinbols. Por trás de todas elas, existem conceitos e princípios que permanecem e é nisso que acredito que vale a pena investir tempo tentando compreender.

Imagine um cenário em que algum conhecido não técnico te pergunta como funciona essa tal de IA e você não faz ideia do que responder. Talvez isso nem fizesse tanta diferença, porque provavelmente ele também não entenderia todos os detalhes, mas eu prefiro não correr o risco de passar essa vergonha.

Então resolvi voltar um pouco ao começo: estudar alguns conceitos fundamentais, implementá-los, tomar notas e transformar essas anotações em uma série de posts para compartilhar essa jornada de aprendizado.

Este primeiro post é sobre implementar e treinar um neurônio artificial capaz de aprender uma relação entre uma entrada X e uma saída Y.

2. O problema

Imagine um canhão que cada vez que ele dispara, você controla a energia do disparo e queremos saber até onde a bala vai chegar.

A pergunta é: dado um valor de energia que nunca usamos antes, conseguimos prever a distância?

energia → [ neurônio ] → distância prevista

É isso que o neurônio vai aprender — não a partir de uma fórmula, mas a partir dos dados que coletamos.

3. O que é um dataset

Alguém foi lá e atirou o canhão 9 vezes e a cada disparo, anotou dois números: a energia usada e a distância que a bala percorreu.

let dataset: Vec<(f64, f64)> = vec![
    (10.0, 28.0),  // energia 10 → bala caiu a 28
    (20.0, 38.0),  // energia 20 → bala caiu a 38
    (30.0, 47.0),
    (40.0, 56.0),
    (50.0, 64.0),
    (60.0, 74.0),
    (70.0, 82.0),
    (80.0, 91.0),
    (90.0, 100.0), // energia 90 → bala caiu a 100
];

Cada par é (energia, distância) e este é o nosso dataset.

É com esses dados que o neurônio vai aprender, ele nunca vê a fórmula por trás, somente os pares. É como tentar descobrir a receita de um prato apenas provando ele várias vezes.

4. A fórmula: y = mx + b

Olhando os dados dá pra perceber: conforme a energia aumenta, a distância aumenta proporcionalmente então podemos descrever esse caso como a equação de uma reta.

y = mx + b descreve uma linha reta. Dado qualquer x, ela devolve um y.

m controla a inclinação — a cada 1 unidade que x avança, y sobe m unidades
b controla onde a reta começa — onde ela cruza o eixo Y quando x = 0

Neste primeiro exemplo, vamos modelar o neurônio como uma transformação linear simples. Em Machine Learning (ML), m e b ganham nomes diferentes:

m → weight
b → bias

Na prática, neurônios em redes mais complexas têm uma função de ativação que introduz curvas e permite aprender padrões não-lineares. Sem ela, combinar vários neurônios ainda resulta numa reta. Mas isso é assunto das fases seguintes — por agora trabalhamos com o neurônio mais simples possível.

5. Implementando o neurônio

Um neurônio artificial, neste contexto, é essa equação aplicada a um problema real.

Para o nosso problema, a tradução fica assim:

y = mx + b -> distância = weight * energia + bias

Ou seja, x vira energia, y vira distância, m vira weight e b vira bias.

pub struct Neuron {
    pub weight: f64,
    pub bias: f64,
}

impl Neuron {
    pub fn predict(&self, x: f64) -> f64 {
        self.weight * x + self.bias
    }
}

let neuron = Neuron { weight: 0.0, bias: 0.0 };

A função predict é literalmente y = mx + b, com weight e bias definidos como zero, pois nosso neurônio ainda não sabe nada.

6. Calculando o erro

Agora que temos nosso neurônio com a função predict implementada, além dos parâmetros weight e bias, precisamos medir o quão boa foi a nossa previsão.

O erro é calculado comparando o valor previsto pelo neurônio com o valor real definido no dataset.

y = mx + b
distância = weight × energia + bias

erro = previsão - valor_real

let predicted = neuron.predict(energy);
let error = predicted - actual;

Visualmente, o estado inicial é esse:

Linha roxa — previsão do neurônio, colada no zero
Bolinhas verdes — os valores reais do dataset
Linhas laranjas — o tamanho do erro em cada ponto

O objetivo é ajustar weight e bias até a linha azul passar por cima das bolinhas e, quando as linhas laranjas sumirem, o neurônio aprendeu.

7. Desenvolvendo o training loop

Agora que conseguimos calcular o erro, precisamos fazer o neurônio melhorar suas previsões.

O training loop consiste em repetir o mesmo processo várias vezes. Cada passagem completa pelo dataset é chamada de uma epoch. A cada epoch, vamos ajustando weight e bias com o objetivo de aproximar a reta dos valores observados.

Para este primeiro exemplo, vamos utilizar uma estratégia bastante simples e totalmente didática, sem ainda entrar em gradient descent ou cálculo de derivadas:

Inicializamos weight e bias com valores (0, 0);
Para cada par do dataset, por exemplo (10, 28), calculamos o erro da previsão;
Se o erro for maior que 0, significa que estamos prevendo um valor maior do que o esperado, então reduzimos weight e bias em 0.01;
Se o erro for menor que 0, significa que estamos prevendo um valor menor do que o esperado, então aumentamos weight e bias em 0.01;
Repetimos esse processo durante 1000 epochs, tentando calibrar os valores de weight e bias.

for epoch in 0..epochs {
    for (energy, actual) in dataset {
        let predicted = self.predict(*energy);
        let error = predicted - actual;

        if error > 0.0 {
            self.weight -= 0.01;
            self.bias -= 0.01;
        } else if error < 0.0 {
            self.weight += 0.01;
            self.bias += 0.01;
        }
    }
}

Essa regra de ajuste foi escolhida porque é fácil de visualizar: quando o neurônio erra para cima, empurramos os parâmetros para baixo; quando erra para baixo, empurramos para cima. Ela melhora o modelo, mas ainda não é o procedimento mais adequado para treino.

Depois de 1000 epochs:

A reta se ajustou. O neurônio aprendeu alguma coisa.

8. As limitações desse método

A reta se ajustou, mas não perfeitamente: ela acerta nos pontos do meio e erra mais nas pontas.

O motivo é que esse algoritmo ajusta sempre pelo mesmo passo fixo (0.01), sem considerar o tamanho do erro, só o sinal. Além disso, ele não usa a inclinação de uma função de perda para decidir a direção e a intensidade ideais do ajuste, então em algum momento começa a oscilar, ultrapassa o valor certo, corrige demais pro outro lado e ultrapassa de novo. Mais epochs não resolve.

O que resolve é o gradient descent, outra forma de tentar reduzir o erro que veremos em um próximo post.

9. Conclusão

Neste post saímos do zero e implementamos um neurônio funcional em Rust.

O que foi aprendido:

Um neurônio artificial é y = mx + b — a equação de uma reta
weight e bias são os parâmetros e são ajustados pelo treino
O dataset é o gabarito e o neurônio aprende olhando exemplos, sem ver a fórmula
O erro mede o quanto o neurônio está errando em cada ponto
O training loop usa o erro para ajustar os parâmetros a cada epoch

Na prática, o que construímos aqui foi um modelo linear simples treinado com uma regra manual de ajuste e isso já é suficiente para entender a intuição central de previsão, erro e correção, mesmo antes de entrar em outros algoritmos.

O que ainda não resolvemos é que o ajuste pelo sinal do erro é simples demais, não considera o tamanho do erro com precisão e pode causar oscilação.

No próximo post: gradient descent, o algoritmo que visa melhorar isso e é uma forte base de todo o aprendizado de máquina moderno.

Referências

Se este post fizer sentido pra você, o próximo passo natural é implementar uma função de perda e depois partir para gradient descent, que é onde o treino começa a ficar mais próximo do que se usa de verdade em Machine Learning.

Programar é uma arte

Alexandre — Tue, 23 Sep 2025 11:59:06 +0000

Assim como desenhar, programar é traduzir o mundo em outra linguagem.

Bons programadores, como bons artistas, não enxergam melhor, mas sabem organizar, escolher e representar melhor.

Índice

1. Introdução
2. Fundamentos
3. Fundamentos da arte
4. Fundamentos da programação
- 4.1. Lógica computacional
- 4.2. Estruturas de dados e algoritmos
- 4.3. Ferramental (Tooling)
- 4.4. Debugging e engenharia reversa
- 4.5. Abstração
6. Conclusão

1. Introdução

No início dos meus estudos em programação, sempre caminhei em paralelo com o estudo de desenho. Durante essa jornada, não pude deixar de traçar paralelos entre as duas áreas. O estudo do desenho sempre me pareceu ter um caminho claro: focar nos chamados fundamentos e praticar. Já na programação, sempre busquei identificar esses fundamentos, mas a definição nunca foi tão evidente.

Neste texto, pretendo explorar o que considero serem os fundamentos da programação.

2. Fundamentos

O que me encanta na ideia de fundamentos é que eles são tópicos inesgotáveis. Você pode estudá-los por toda a vida, e ainda assim haverá sempre mais a aprender. É como anatomia no desenho: você pode aprofundar infinitamente, desde o estudo dos ossos até a simplificação de formas para criar estilos exagerados ou minimalistas. Mas, para que o resultado seja intencional e convincente, precisa estar bem fundamentado.

Da mesma forma, um bom desenho ou um bom programa depende da aplicação equilibrada de vários fundamentos ao mesmo tempo. Dominar apenas um não garante um bom resultado final. Os fundamentos não são uma lista que se esgota, mas pontos de prática constante — como um boxeador que treina o mesmo soco todos os dias até que se torne instintivo.

3. Fundamentos da arte

Como este é um artigo focado em programação, muitos podem não ter tido contato com os fundamentos da arte. Então farei uma breve explicação para seguirmos:

Linhas: o elemento mais básico para definir contorno, forma e dar sensação de movimento.
Formas: blocos de construção de qualquer objeto, representados por figuras geométricas básicas como círculos, quadrados e triângulos. Simplificar a realidade em formas ajuda a construir o desenho de maneira mais precisa.
Perspectiva: permite criar a ilusão de profundidade e tridimensionalidade em uma superfície plana.
Anatomia: essencial para desenhar pessoas e animais de maneira realista e proporcional. É o estudo da estrutura corporal, músculos e ossos.
Composição: refere-se à organização visual dos elementos dentro do espaço. Envolve a disposição, o equilíbrio e a distribuição de objetos, cores e linhas para criar uma obra harmoniosa.

4. Fundamentos da programação

4.1. Lógica computacional

Capacidade de entender uma necessidade e transformá-la em um programa. Observe como um desenhista enxerga formas simples (círculos, quadrados) em uma figura complexa.

LINK

O programador deve ter a habilidade de enxergar processos complexos e representa-los de forma simplificada.

Exemplo: imagine um programador conversando com um cliente sobre um novo projeto. O cliente descreve um fluxo de contratação totalmente manual, que envolve diversos setores, diferentes níveis de permissão, etapas de aprovação, envio de e-mails e muitos outros detalhes.

O papel do programador é extrair, simplificar e organizar esses fluxos, transformando a descrição em um modelo compreensível. Só assim será possível apresentar ao cliente quais funcionalidades serão desenvolvidas e como elas vão funcionar.

4.2. Estruturas de dados e algoritmos

São formas de organizar e processar informações. Assim como um artista usa a composição para distribuir elementos em uma cena, o programador utiliza estruturas para dar ordem e eficiência aos dados.

Observe essas 2 artes

Na primeira arte, não há técnicas de composição evidentes; já na segunda, o olhar do observador é conduzido intencionalmente pelos elementos, seguindo o caminho que o artista planejou.

Da mesma forma, um programador deve saber escolher as estruturas de dados e algoritmos adequados para guiar o fluxo das informações. Usar um array para armazenar uma lista telefônica pode até funcionar, mas não será a decisão mais eficiente — nesse caso, uma estrutura de mapa permitiria buscas muito mais rápidas e organizadas.

// Lista telefônica usando Vec
let lista_telefonica = vec![
    ("Peter", "1111-1111"),
    ("Carlos", "2222-2222"),
    ("Jordan", "3333-3333"),
];

// Procurar telefone do Jordan em um Vec (O(n))
let mut telefone = None;
for (nome, numero) in &lista_telefonica {
    if *nome == "Jordan" {
        telefone = Some(*numero);
        break;
    }
}

println!("Telefone do Jordan (Vec): {:?}", telefone.unwrap());

// Lista telefônica usando HashMap
let mut lista_telefonica_map = HashMap::new();
lista_telefonica_map.insert("Peter", "1111-1111");
lista_telefonica_map.insert("Carlos", "2222-2222");
lista_telefonica_map.insert("Jordan", "3333-3333");

// Procurar telefone do Jordan em HashMap (O(1))
if let Some(numero) = lista_telefonica_map.get("Jordan") {
    println!("Telefone do Jordan (HashMap): {}", numero);
}

Dominar essas estruturas — e os algoritmos que as acompanham — é essencial para compor sistemas complexos. Cada estrutura tem pontos fortes e fracos, e saber quando aplicar cada uma delas é o que diferencia soluções simples de ótimas composições.

4.3. Ferramental (Tooling)

Assim como um artista que utiliza uma mesa digitalizadora consegue desenhar mais rápido, com maior precisão e explorar possibilidades criativas que seriam muito mais trabalhosas no papel, o programador também pode acelerar e ampliar sua capacidade ao dominar suas ferramentas.

O uso de LLMs para gerar código ou documentação, scripts de automação para eliminar tarefas repetitivas, Docker para garantir ambientes consistentes e até sistemas como o Nix para reproduzir setups complexos traz não apenas mais velocidade, mas também conforto e segurança no dia a dia de desenvolvimento.

Aprender e dominar essas ferramentas é tão importante quanto aprender uma linguagem de programação: são elas que permitem transformar esforço bruto em eficiência, garantindo que o desenvolvedor trabalhe com mais fluidez e tenha liberdade para explorar soluções mais sofisticadas.

4.4. Debugging e engenharia reversa

Um bom desenvolvedor deve ser capaz de “executar mentalmente” o código, acompanhando cada fluxo de decisão (if, switch) e cada loop (for, while) como se estivesse rodando o programa na cabeça.

fn calcular_frete(valor: f64, destino: &str) -> f64 {
    if valor <= 0.0 {
        return 0.0;
    }

    // Frete grátis para pedidos acima de 500
    if valor > 500.0 {
        return 0.0;
    }

    // Destino prioritário tem taxa fixa
    if destino == "capital" {
        return 20.0;
    }

    // Valor padrão
    50.0
}

Você não deve precisar perder tempo executando esse código com todas as suas possibilidades para debugar, enquanto escreve já deve ser capaz de executar as possibilidades de entrada e saída para a função.

O verdadeiro desafio surge quando algo dá errado: muitas vezes o erro aparece apenas como uma mensagem no console ou um comportamento inesperado na tela do cliente, enquanto a causa real está escondida em camadas mais profundas.

Depurar significa seguir esse rastro, passo a passo, de cima para baixo, até chegar à raiz do problema. É como um artista que olha para um desenho “estranho” e percebe que a falha não está na pintura final, mas em uma proporção incorreta do esboço inicial. Ter essa habilidade de engenharia reversa, de reconstruir o caminho do erro até sua origem, é o que transforma um desenvolvedor comum em um solucionador de problemas eficiente.

4.5. Abstração

Abstração é o ato de simplificar: olhar para um problema complexo e destacar apenas os pontos essenciais.

Um pintor não precisa desenhar cada fio de cabelo, apenas sugerir volume e textura.

Observe essa pintura

Note que o artista não precisou pintar cada detalhe da cena, alguns elementos da pintura são somente pinceladas; ele concentrou-se no ponto de interesse e deixou de lado elementos desnecessários. Ainda assim conseguimos identificar claramente uma criatura em um pasto de animais com montanhas ao fundo.

Em programação, as abstrações existem para organizar o caos. Ao criar uma função como sendEmail, o que realmente importa é a intenção: “enviar um e-mail”. Se será por API, SMTP ou outro provedor é apenas um detalhe de implementação, que deve ser abstraído para poder mudar sem impactar o restante do sistema. Esse isolamento torna o código mais limpo, reutilizável e fácil de manter.

Conclusão

Estudar fundamentos não significa que você dominará tudo, mas sim que terá a base sólida para evoluir. Conhecer os fundamentos permite aplicá-los de forma consciente, adaptá-los e até quebrar regras quando necessário, da mesma forma que um artista usa formas circulares para transmitir suavidade, mas pode inverter a lógica para transmitir algo inesperado.

O essencial é entender que fundamentos não se esgotam: quanto mais você pratica, mais naturais se tornam, e mais liberdade você ganha para criar, inovar e resolver problemas de maneira original.

Rust Threads safety: Uma comparação com C.

Alexandre — Mon, 18 Nov 2024 22:54:10 +0000

Nesta POC (Proof of Concept), exploraremos como a linguagem Rust trata as race conditions, comparando-a com C, uma linguagem amplamente usada, mas com menos garantias de segurança para concorrência.

Rust Threads safety: Uma Comparação com C

Threads Safety: Data Races de C ao Rust

Índice

1. Introdução
2. Threads
3. Implementação em C
- 3.1. Código sem Proteção Contra Race Conditions
- 3.2. Corrigindo com Mutex
4. Implementação em Rust
- 4.1. Problema com Race Conditions
- 4.2. Resolução com Mutex e Arc
- 4.3. Mutex vs. RwLock
5. Conclusão
6. Referências

1. Introdução

Em computação, threads são usadas para dividir tarefas de software em subtarefas que podem ser executadas concorrentemente. Ao usar threads, ganhamos tempo de processamento e aproveitamos melhor os recursos da máquina, mas essa concorrência traz desafios, como race conditions que podem gerar inconsistências graves nos dados.

2. Threads

Threads são unidades de execução que permitem processar tarefas simultaneamente. Podemos pensar em threads como fluxos independentes de execução dentro de um programa, ilustrados na imagem abaixo:

Embora as threads tragam vantagens de desempenho, elas introduzem riscos, especialmente ao acessar recursos compartilhados.

Além disso, threads podem ser usadas para implementar paralelismo, onde múltiplas tarefas são executadas simultaneamente em diferentes núcleos de CPU. Isso permite que o programa aproveite melhor o hardware disponível, acelerando a execução de tarefas independentes.

3. Implementação em C

Vamos criar um sistema simples em C:

Um saldo inicial de 1000.
Um conjunto de transações que podem ser créditos ou débitos.
Processamento paralelo dessas transações usando threads.

3.1. Código sem Proteção Contra Race Conditions

int saldo = 1000; 

void creditar(int valor) {
    int tmp_saldo = saldo;

    sleep(1); // Delay simulado

    saldo += tmp_saldo + valor;
}

void debitar(int valor) {
    int temp = saldo;

    sleep(1); // Delay simulado

    if (temp >= valor) {
        saldo = temp - valor;
    }
}

void* processar_transacao(void* arg) {
    int valor = *(int*)arg;

    if (valor > 0) {
        creditar(valor);
    } else {
        debitar(abs(valor));
    }

    return NULL;
}

int main() {
    int transactions[] = {100, -50, 200, -150, 300, -200, 150, -100, 50, -50};
    int num_transactions = sizeof(transactions) / sizeof(transactions[0]);

    pthread_t threads[num_transactions];

    for (int i = 0; i < num_transactions; i++) {
        pthread_create(&threads[i], NULL, processar_transacao, &transactions[i]); // Cria uma thread para cada transação
    }

    for (int i = 0; i < num_transactions; i++) {
        pthread_join(threads[i], NULL); // Aguarda todas as threads terminarem
    }

    printf("Saldo final da conta: %d\n", saldo);
    return 0;
}

Ao optarmos por um ambiente com processamento multithreading pode acontecer o que chamamos de race conditions, no momento em que 2 threads acessam e modificam um mesmo valor temos uma condição de corrida. Esse problema acontece pois não é garantido uma sincronização do valor acessado em cada thread devido à concorrência entre as chamadas.

Ao executar várias vezes esse código, o saldo final varia, pois threads acessam e alteram saldo simultaneamente.

3.2. Corrigindo com Mutex

int saldo = 1000; 
pthread_mutex_t saldo_mutex; // Mutex para proteger o saldo

void creditar(int valor) { 
    pthread_mutex_lock(&saldo_mutex); // Bloqueia o mutex
    int tmp_saldo = saldo;

    sleep(1); // Delay simulado

    saldo = tmp_saldo + valor;

    pthread_mutex_unlock(&saldo_mutex); // Libera o mutex
}

void debitar(int valor) {
    pthread_mutex_lock(&saldo_mutex); // Bloqueia o mutex
    int tmp_saldo = saldo;

    sleep(1); // Delay simulado

    if (tmp_saldo >= valor) {
        saldo = tmp_saldo - valor;
    }

    pthread_mutex_unlock(&saldo_mutex);  // Libera o mutex
}

Mutex é um primitivo de sincronização que garante que apenas um thread tenha acesso a um recurso compartilhado por vez. O acrônimo mutex vem do termo em inglês mutual exclusion, que significa "exclusão mútua".

Quando uma thread adquire um mutex, qualquer outra thread que tente adquirir o mesmo mutex é suspenso até que a primeira thread libere o mutex. Isso evita que dois ou mais processos(threads) tenham acesso simultâneo ao recurso compartilhado.

4. Implementação em Rust

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.

Pensar em Rust como uma linguagem ausente de data race não é produtivo, mas podemos entender como as structs e seu compilador contribuem trazendo recursos ótimos para segurança de memória e thread.

Rust trata race conditions com garantias em tempo de compilação, utilizando recursos como ownership, borrowing e estruturas seguras para concorrência:

Arc: Compartilhamento seguro de dados imutáveis.
Mutex e RwLock: Controle de acesso para dados mutáveis.

4.1. Problema com Race Conditions

Sem o uso das structs Arc e Mutex

fn main() {
    let mut saldo = 1000; // saldo mutável, mas sem proteção

    let handle1 = thread::spawn(move || {
        saldo += 100;  // erro: `saldo` é movido para esta thread sem proteção
    });

    let handle2 = thread::spawn(move || {
        saldo -= 50;  // erro: `saldo` é movido para esta thread sem proteção
    });

    handle1.join().unwrap();
    handle2.join().unwrap();
}

Rust não permite o acesso direto a um dado mutável (saldo) a partir de várias threads sem proteção.
O compilador vai gerar um erro porque saldo está sendo movido para várias threads (handle1 e handle2) sem um mecanismo seguro.
Mensagem de erro que será exibida é:

error[E0382]: use of moved value: `saldo`

4.2. Resolução com Mutex e Arc

Usando Mutex e Arc conseguimos compilar e executar nosso código, com os problemas de race condition tratados.

struct ContaBancaria {
    saldo: i32,
}

impl ContaBancaria {
    fn creditar(&mut self, valor: i32) {
        let tmp_saldo = self.saldo;
        thread::sleep(time::Duration::from_secs(1));
        self.saldo = tmp_saldo + valor;
    }

    fn debitar(&mut self, valor: i32) {
        let tmp_saldo = self.saldo;

        thread::sleep(time::Duration::from_secs(1));

        if tmp_saldo >= valor {
            self.saldo = tmp_saldo - valor;
        }
    }

    fn consultar_saldo(&self) -> i32 {
        self.saldo
    }
}

fn main() {
    let conta = Arc::new(Mutex::new(ContaBancaria { saldo: 1000 }));  // Cria a conta com Arc

    let mut handles = vec![];
    let transactions = [100, -50, 200, -150, 300, -200, 150, -100, 50, -50];

    for transaction in transactions {
        let conta = Arc::clone(&conta);

        let handle = thread::spawn(move || {
            let random_sleep_time = rand::thread_rng().gen_range(0..10);
            thread::sleep(time::Duration::from_secs(random_sleep_time));

            if transaction > 0 {
                conta.lock().unwrap().creditar(transaction);
            } else {
                conta.lock().unwrap().debitar(transaction.abs());
            }
        });

        handles.push(handle);
    }


    for handle in handles {
        handle.join().unwrap(); // Espera todas as threads terminarem
    }

    let saldo_final = conta.lock().unwrap().consultar_saldo();
    println!("Saldo final da conta: {}", saldo_final);
}

4.3. Mutex vs. RwLock

Mutex e RwLock são usados para tratar race conditions, cada um com vantagens específicas:

Mutex: Garante acesso exclusivo de um recurso para uma thread, bloqueando o acesso das outras até seja liberado. É simples e eficaz, mas mesmo leituras bloqueiam o recurso, tornando-o menos eficiente em cenários com muitas leituras.

RwLock: Permite múltiplas leituras simultâneas com .read() e restringe a escrita exclusiva com .write(). É Ideal para cenários com predominância de leituras, pois melhora o desempenho ao permitir paralelismo nas operações de leitura.

5. Conclusão

A comparação entre C e Rust destaca abordagens diferentes para resolver race conditions. Enquanto C exige atenção para evitar erros de condições de corrida, Rust reduz esses riscos em tempo de compilação, por meio de ferramentas como Mutex, RwLock e Arc além do modelo de ownership. Isso não apenas torna o código mais seguro, mas também reduz a carga mental do programador evitando bugs silenciosos.

Em resumo, Rust se posiciona como uma excelente escolha para o desenvolvimento de sistemas concorrentes, oferecendo segurança e confiabilidade.

6. Referências

Schemas em SQL: Indexes e B+ trees

Alexandre — Thu, 19 Oct 2023 18:21:27 +0000

Indexes e B+ trees qual será a relação dessa engraçada estrutura de dados com nossos queridos indexes do banco?

Conteúdo

1 Prólogo
2 O que são indexes
3 B Tree e B+ Tree
4 Vamos observar na prática
5 Conclusão
6 Referências

1 Prólogo

O que são indexes e como eles são usados para optimizar buscas? quantas vezes já não adicionamos indexes em colunas de tabelas com milhares de registros e magicamente as queries caíram de alguns segundos para milissegundos, nunca foi magica e sim Computer Science.

2. O que são indexes

Index são uma estrutura separada da estrutura dos registros tabela, sendo feita uma cópia de uma parte dos seus dados, que servem como um ponteiro para acessar um registro específico.

Quando pensamos em criar index existe um conceito que podemos seguir "As many as you need, As few as you can get away with", em outras palavras, você deve criar índices suficientes para acelerar as consultas e melhorar o desempenho, mas não deve criar muitos índices desnecessários, pois isso pode aumentar o espaço de armazenamento e a sobrecarga inserções no banco de dados, já que sempre que um registro for inserido vão ser criados também os indexes existentes.

Então como sei quais index criar? Para criar seus indexes é preciso olhar para queries que pretende executar, para montar um bom schema olhamos para os dados que vamos armazenar, já para bons indexes olhamos para as queries estamos executando ou pretendemos executar.

3. B Tree e B+ Tree

Como foi dito os indexes são partes dos seus dados armazenados em uma estrutura diferente, essa estrutura é a B+Tree, antes de entendermos ela precisamos compreender a B Tree.

B Tree é uma estrutura não lineares diferentes de um Array, que somente podemos ir para frente e para trás com as árvores podemos navegar para níveis e subníveis dentro dela.

A B Tree diferente a Binary Tree permite que armazenemos mais de um valor por nó, como na imagem de exemplo onde o primeiro nó tem 2 valores 20 e o 40 permitindo que tenhamos um bloco de valores em cada nó que recebem o nome de página.

B+tree é a estrutura de dados que está por trás das buscas optimizadas que o banco faz, é uma estrutura derivada das BTrees, mas com uma forma diferente de armazenar suas chaves de uma maneira que o processamento sequencial e aleatório de chaves fossem eficientes, sendo bastante usadas em bancos de dados como MYSQL e sistemas de arquivo como FTP.

A principal diferença de estrutura das duas é que a B+ os dados são armazenados apenas nas folhas(Nós finais, que não tem filhos), e seus nós internos armazenam ponteiros para os filhos e suas folhas são uma linked list facilitando assim uma busca sequencial de valores se adequando bem melhor para o contexto de bancos de dados, já a B Tree é mais versátil permitindo um uso em uma variedade maior de contextos.

4. Prática

Vamos observar como uma query usa index para encontrar os dados e como seria essa mesma busca se não usássemos os index.

SELECT * FROM users;  
EXPLAIN SELECT * FROM users WHERE name='Virux';

Como o SQL fez para encontrar um user baseado no nosso where ?

Sem um índice, o MySQL vai ler toda a tabela do início ao fim encontrando os valores desejados, conseguimos comprovar isso observando valor all no campo type que o EXPLAIN nos retorna, ou seja, quanto maior a tabela mais lenta a busca, como Virux é o registro 9 ele precisou ler 8 registros até encontrar o desejado.

Executando isso o SQL vai criar um index para esse campo

CREATE INDEX idx_name ON users (name(255));

Agora se a coluna name tiver um index executando a mesma busca será feita de uma forma mais optimizada, buscando na estrutura da B+Tree que o mysql montou com os seus dados, conseguimos identificar isso com o valor ref no campo type que o EXAPLAIN nos retorna.

Podemos encontrar esse registro com somente 3 etapas.

5. Conclusão

Com isso podemos concluir que buscar usando index são bem mais optimizadas, pois são feitas em uma estrutura de dados separada da sua tabela chamada B+Tree, mas precisamos criar nossos index com cuidado pensando nas queries que pretendemos executar, pois eles afetam diretamente a desempenho das inserções além de aumentar o espaço de armazenamento.

6. Referências

B+Tree Wiki
B+Tree Vizualize
Doc do mysql sobre index

Garanta a Eficiência: Escolhendo entre tipos String no SQL

Alexandre — Tue, 29 Aug 2023 12:27:27 +0000

Garanta a eficiência, nova série fazendo mais sucesso que The Walking Dead, venha aprender como salvar seus strings no seu banco sql.

Conteúdo

1 Prólogo
2 CHAR
3 VARCHAR
4 CHARSET e COLLATE
5 Conclusão

1. Prólogo

Dando continuidade à nossa série, já abordamos os valores numéricos agora, chegou a hora de nos aprofundarmos nas strings. Neste artigo, exploraremos as diferenças entre os tipos VARCHAR e CHAR, além de fornecer uma compreensão detalhada sobre os conceitos de CHARSET e COLLATE, os quais você certamente já encontrou em seus bancos de dados, mas talvez ainda não tenha uma ideia clara de suas finalidades.

2. CHAR

O tipo de dado CHAR no MySQL é usado para armazenar strings de comprimento fixo.

Se o valor de uma string CHAR tiver um comprimento menor do que o comprimento especificado, os espaços em branco serão adicionados automaticamente ao final da string para preencher o espaço restante. Esses espaços em branco serão incluídos.

O tipo de dado CHAR é usado principalmente quando você precisa armazenar strings de comprimento fixo ou quando há um requisito específico para o tamanho da string. As comparações e pesquisas em colunas CHAR são mais rápidas do que em colunas VARCHAR porque não há necessidade de levar em consideração o tamanho variável.

3. VARCHAR

O tipo de dado VARCHAR armazena strings de comprimento variável, o que significa que o tamanho ocupado no armazenamento depende do comprimento real da string. Por exemplo, se você definir uma coluna VARCHAR(255) e inserir uma string de apenas 10 caracteres, ela ocupará apenas a quantidade de espaço necessária para armazenar esses 10 caracteres.

O tipo de dado VARCHAR pode ser mais eficiente em termos de armazenamento em comparação com o tipo de dado CHAR se a maioria das strings armazenadas tiver comprimentos variáveis. Isso ocorre porque o espaço alocado para armazenar a string é proporcional ao comprimento real da string e não ao comprimento máximo especificado.

O tipo de dado VARCHAR requer espaço adicional de armazenamento para registrar o comprimento real da string. Esse espaço extra varia de 1 a 2 bytes, dependendo do tamanho máximo especificado para a coluna VARCHAR.

4. CHARSET e COLLATE

CREATE TABLE strings (
    fixed100 CHAR(100), -- 100 bytes "Aaron     ..."
    var100 VARCHAR(100) -- 5 bytes + 1 Byte "Aaron"
);

SHOW CREATE TABLE strings;

CREATE TABLE `strings` (
  `fixed100` char(100) DEFAULT NULL,
  `var100` varchar(100) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

SELECT * FROM information_schema.CHARACTER_SETS ORDER BY CHARACTER_SET_NAME;

CHARSET (utf8mb4)

O CHARSET utf8mb4 é uma configuração no MySQL que define o conjunto de caracteres utilizado para armazenar dados em colunas de texto. Nesse caso, o utf8mb4 refere-se a um conjunto de caracteres multibyte que suporta a codificação UTF-8.

utf8: Refere-se ao conjunto de caracteres UTF-8, que é um padrão universalmente aceito para representação de caracteres em várias línguas e scripts. O UTF-8 é capaz de representar uma ampla gama de caracteres e é amplamente utilizado em sistemas modernos.
mb4: É uma abreviação de "multibyte 4", indicando que o conjunto de caracteres suporta até 4 bytes por caractere. Isso permite a representação de caracteres que requerem mais de 2 bytes, como emojis e caracteres especiais de diferentes idiomas.

COLLATE (utf8mb4_0900_ai_ci)

A cláusula COLLATE é usada para definir a ordem de classificação de caracteres em operações de comparação e classificação de texto. No caso específico do COLLATE utf8mb4_0900_ai_ci, é uma sequência de configuração que define a ordem de classificação. Essas definições são as seguintes:

utf8mb4: É um conjunto de caracteres que suporta a codificação UTF-8 de caracteres multibyte. O UTF-8 é um padrão universalmente aceito para representação de caracteres e suporta uma ampla gama de caracteres de diferentes idiomas.
0900: É um indicador da versão do algorítimo usado. Neste caso, 0900 refere-se à versão do Unicode Collation Algorithm (ou UCA). As versões mais recentes do MySQL podem introduzir atualizações e melhorias nos conjuntos de caracteres existentes.
ai: É uma abreviação de "Accent Insensitive" (insensível a acentos). Isso significa que as comparações de caracteres são realizadas sem levar em consideração os acentos. Por exemplo, as letras "á" e "a" seriam consideradas iguais.
ci: É uma abreviação de "Case Insensitive" (insensível a maiúsculas e minúsculas). Isso significa que as comparações de caracteres são realizadas sem levar em consideração a diferença entre letras maiúsculas e minúsculas. Por exemplo, as letras "A" e "a" seriam consideradas iguais.

5. Conclusão

Neste artigo, exploramos a diferença entre os tipos de string VARCHAR e CHAR no MySQL. Aprendemos que o CHAR é ideal para tamanhos fixos, enquanto o VARCHAR é mais adequado para tamanhos variáveis. Além disso, compreendemos o papel do CHARSET e COLLATE, permitindo personalizar a ordenação de texto.

Com esse conhecimento, podemos tomar decisões mais acertadas ao projetar nossas tabelas no MySQL, garantindo a eficiência e o desempenho ideais para nossas aplicações. A escolha inteligente dos tipos de string e configurações de charset/collate é crucial para um banco de dados otimizado e bem-sucedido.

Garanta a Eficiência: Escolhendo entre tipos decimais no SQL

Alexandre — Wed, 12 Jul 2023 00:30:56 +0000

Decimais, existem tantos e qual devo escolher ? Saiba que essa decisão é de total importância para não perder dinheiro em seu software.

Conteúdo

Prólogo
Tipos decimais SQL
O que é essa precisão ?
Então quando eu não ira querer precisão
Vamos observar na prática
Conclusão

1. Prólogo

Sempre tive dúvidas sobre a razão pela qual existem tantos tipos de dados decimais no SQL e quando é apropriado utilizá-los, especialmente ao lidar com valores monetários, onde a consistência dos cálculos e a precisão são fundamentais para evitar perdas financeiras. Muitos desses tipos de dados são desconhecidos ou subutilizados no cotidiano de um desenvolvedor web. No entanto, estar ciente dos seus casos de uso diferenças é uma vantagem significativa para quando precisar usar você conseguir identificar.

2. Tipos decimais SQL

Existem diversos tipos de dados decimais disponíveis no SQL, cada um com seu próprio propósito e comportamento. Vamos explorar alguns dos tipos mais comuns:

DECIMAL/NUMERIC

O tipo DECIMAL possui um alias (apelido) chamado NUMERIC, ou seja ambos têm o mesmo comportamento. Esse tipo é especialmente adequado para lidar com valores precisos, como dinheiro, onde é crucial manter a exatidão das informações.

FLOAT

O tipo FLOAT é recomendado para valores aproximados, como estatísticas, por serem eficientes em termos de espaço de armazenamento e desempenho, ocupando um total de 4 bytes de espaço de armazenamento.

DOUBLE

O campo DOUBLE também é apropriado para valores aproximados, mas oferece um range de valores maior em comparação ao FLOAT. Para acomodar essa flexibilidade, ele requer 8 bytes de espaço de armazenamento.

3. O que é essa precisão ?

Essa precisão é você saber que se um cliente comprar 2 produtos que custam R$ 20,30 ele vai pagar R$ 20,60 e não R$ 20,59999931231232321.

4. Então quando eu não ira querer precisão ?

Embora o float possa introduzir variações nos cálculos, há casos de uso em que eles são vantajosos na prática. Aqui estão dois exemplos:

Cálculos científicos e simulações: Em muitas áreas da ciência e da engenharia, os cálculos envolvem números que não exigem uma precisão extrema. Nesses casos, o uso de float pode ser adequado, pois oferece uma representação aproximada dos valores com eficiência de espaço e desempenho. Por exemplo, em simulações físicas, como modelos de sistemas climáticos ou mecânicos, a precisão aproximada fornecida pelos números de ponto flutuante é suficiente e pode acelerar significativamente os cálculos.
Processamento gráfico: Em aplicações de computação gráfica, como jogos ou renderização de imagens, o uso de float é comum para representar coordenadas 3D, cores e transformações. A natureza aproximada dos números de ponto flutuante não é perceptível para a maioria dos usuários, e a velocidade de processamento é fundamental nesses casos.

5. Vamos observar na prática

Criaremos uma tabela para testes chamada decimals

CREATE TABLE decimals (
  n INT,
  d1 DECIMAL(10, 2),
  d2 FLOAT, -- 4 bytes
  d3 DOUBLE -- 8 bytes
);

INSERT INTO decimals
VALUES
(1, 100.40, 100.40, 100.40),
(1, -80.00, -80.00, -80.00);

SELECT sum(d1), sum(d2), sum(d3) FROM decimals GROUP BY n;

Ao executar o SELECT vamos ter o seguinte resultado

sum(d1)	sum(d2)	sum(d3)
20.40	20.400001525878906	20.400000000000006

Nesse exemplo, criamos uma tabela chamada "decimals" com três colunas: "d1" do tipo DECIMAL(10, 2), "d2" do tipo FLOAT e "d3" do tipo DOUBLE. Em seguida, inserimos duas linhas de dados nessa tabela.

Ao realizar a soma dos valores de cada coluna usando a cláusula GROUP BY, podemos observar as diferenças resultantes. A coluna "d1", que utiliza o tipo DECIMAL com precisão fixa de duas casas decimais, apresenta um resultado preciso de 20.40.

No entanto, as colunas "d2" (FLOAT) e "d3" (DOUBLE) demonstram as variações típicas dos números de ponto flutuante. Embora os valores somados sejam teoricamente iguais a 20.40, devido à representação aproximada desses tipos, ocorrem pequenas variações nos resultados. Essas variações podem ocorrer devido a erros de arredondamento ou limitações na precisão dos bits usados para representar os números.

Essas diferenças podem parecer insignificantes, mas em casos que exigem precisão exata, como manipulação de valores monetários, elas podem levar a perdas ou erros nos cálculos financeiros.

6. Conclusão

Exploramos os diferentes tipos de dados decimais no SQL e destacamos a importância de escolher o tipo correto com base nas necessidades específicas. Ao lidar com valores monetários e cálculos que exigem precisão absoluta, é recomendado utilizar tipos decimais de precisão fixa, como DECIMAL ou NUMERIC. Esses tipos garantem resultados consistentes e evitam perdas de valor.

Embora os números de ponto flutuante (float) possam ser vantajosos em determinados cenários, e*les podem introduzir variações nos cálculos* devido à natureza aproximada da representação. É essencial avaliar o contexto e a precisão necessária para evitar problemas de arredondamento.

Garanta a Eficiência: Escolhendo Sabiamente o Tipo de Dado Integer no MySQL

Alexandre — Tue, 04 Jul 2023 18:16:05 +0000

Já pensou no motivo de um banco de dados ter tantos tipos de valores inteiros? SMALLINT? BIGINT? É de comer?

Conteúdo

Prólogo
Escolhendo tipos em modelos de dados
Tomando uma decisão consciente
O que posso fazer um Byte ?
Agora vamos colocar em prática
Considerações finais

1. Prólogo

Nessa vida de desenvolvedor de software, aprendi a valorizar os fundamentos das tecnologias com as quais trabalho. Neste artigo, vamos explorar todos os tipos INTEGER existentes, quais suas características e como podemos usar isso para tomar decisões mais assertivas ao modelar um esquema com MySQL.

2. Escolhendo tipos em modelos de dados

Um princípio fundamental para modelar dados é avaliar se os tipos escolhidos são os melhores para os valores que serão recebidos. Nesse artigo vamos tentar entender quais tipos de inteiros existem e quais suas diferenças para podermos tomar essa melhor decisão no momento de criar nossas tabelas.

3. Tomando uma decisão consciente

Para conseguirmos tomar a decisão mais consciente precisamos saber quais o tipos de inteiro existentes e qual o espaço ocupado em Bytes por cada tipo, pois independente de você inserir o número inteiro 1 em um registro ele ocupa um espaço diferente de acordo com o tipo de dado do schema.

Por exemplo, o tipo TINYINT ocupa 1 byte, enquanto o tipo BIGINT ocupa 8 bytes. Portanto, mesmo que você insira o número inteiro 1 em um registro, ele ocupará um espaço diferente dependendo do tipo de dado especificado no esquema (schema).

Podemos considerar que cada tipo de inteiros nos permitem armazenar um certo range de valores e cada range reserva uma quantidade de Bytes.

Vamos observar todos os tipos e seus custos de Bytes:

Type	Storage (Bytes)
TINYINT	1
SMALLINT	2
MEDIUMINT	3
INT	4

4. O que posso fazer um Byte ?

Com 1 Byte podemos usar 8 Bits, ou seja com o TINYINT podemos armazenar números no seguinte range:

00000000 = 0
11111111 = 255

E caso precisarmos ter um sinal ? Nesse caso vamos precisas separar um bit para isso reduzindo nosso range assim:

0 1111111 = -128 (negative bit)
1 1111111 = 127 (positive bit)

Com isso temos a seguinte tabela:

Type	Storage (Bytes)	Min Signed	Max Signed	Max Unsigned
TINYINT	1	-128	127	255
SMALLINT	2	-32768	32767	65535
MEDIUMINT	3	-8388608	8388607	16777215
INT	4	-2147483648	2147483647	4294967295
BIGINT	8	-2^63	2^63-1	2^64-1

5. Agora vamos colocar em prática

CREATE TABLE `books` (
    `id` bigint NOT NULL AUTO_INCREMENT,
    `title` varchar(100) NOT NULL,
    `num_pages` SMALLINT UNSIGNED, 
     PRIMARY KEY (id)
);

Nesse trecho de SQL, tomamos a decisão de escolher o tipo de inteiro mais adequado com base no contexto do nosso caso de uso. Ao analisar a coluna num_pages, que representa o total de páginas de um livro, optamos por utilizar o tipo SMALLINT. Essa escolha foi feita levando em consideração os seguintes fatores:

1. Valor máximo adequado: O tipo TINYINT possui um valor máximo de 255, o qual poderia ser facilmente ultrapassado por livros com um número significativo de páginas. No entanto, o tipo SMALLINT oferece um tamanho maior, permitindo um valor máximo de 65535. Essa faixa é mais adequada para a representação do número de páginas de um livro na vida real a não ser que você esteja lendo Game of Thrones, ai já seria preciso de um BIGINIT.

2. Modificador UNSIGNED: Utilizamos o modificador UNSIGNED para indicar que não há necessidade de armazenar valores negativos para o número de páginas de um livro. Isso nos permite aproveitar um limite positivo maior dentro do mesmo tipo de dado, já que não precisamos reservar espaço para o sinal.

Portanto, ao escolher o tipo SMALLINT UNSIGNED para a coluna num_pages, levamos em consideração o valor máximo adequado, a economia de espaço e a exclusão da possibilidade de valores negativos, garantindo uma representação eficiente e precisa do número de páginas dos livros em nosso sistema.

6. Considerações finais

Após compreendermos as diferenças entre os tipos de inteiro, percebi o quanto é importante escolher o tipo de dado adequado para cada situação. Refletindo sobre minha própria experiência, lembro-me das vezes em que utilizei o tipo INTEGER desnecessariamente. Após aprofundar-me nesse assunto e compartilhar essas informações, acredito que não vou mais cometer esse erro. Espero que este artigo tenha sido esclarecedor para vocês também, auxiliando na escolha consciente do tipo de inteiro mais adequado para cada contexto.

Venha fazer parte de um ambiente de aprendizado.