O perceptron é um daqueles modelos que parecem simples demais à primeira vista.

Mas tem um detalhe importante:

ele já contém a ideia essencial de aprendizado

Mesmo que de forma limitada.

Mais do que um exercício

A implementação em si não tem mistério.

Um somatório, uma função de ativação, ajuste de pesos.

Mas a intenção aqui não foi só implementar.

Foi entender o comportamento:

• o que ele aprende
• como ele aprende
• onde ele simplesmente não consegue ir

O modelo

A decisão do perceptron é baseada em uma combinação linear das entradas:

Isso define uma fronteira de decisão — uma linha (ou hiperplano, em dimensões maiores).

É só isso.

Esse modelo deriva diretamente da ideia de neurônio artificial, que descrevi aqui.

A função de ativação utilizada é um degrau bipolar. Também escrevi uma nota sobre isso aqui.

Durante o treinamento, os pesos são ajustados sempre que o modelo erra:

Nada sofisticado — mas suficiente para capturar padrões simples.

Onde ele funciona

Quando os dados podem ser separados por uma linha, ele converge.

Casos simples deixam isso claro:

• AND
• OR

Aqui, o modelo aprende rápido e se ajusta sem dificuldade.

Onde ele quebra

O problema aparece quando a separação deixa de ser linear.

O exemplo clássico é o XOR.

Não importa o quanto você treine:

o modelo não converge

E isso não é falha da implementação — é limitação do próprio modelo.

O que isso mostra

Esse ponto é mais interessante do que parece.

Porque ele revela algo fundamental:

o modelo não aprende “qualquer coisa” — ele aprende o que a sua forma permite

No caso do perceptron, essa forma é linear.

Se o problema exige algo além disso, ele simplesmente não consegue representar.

Visualização

A parte mais interessante é ver a fronteira de decisão se ajustando ao longo do treino.

Ver isso acontecendo deixa o processo menos abstrato.

O modelo ajusta os pesos, move a fronteira e tenta corrigir erros — mas sempre dentro do que ele consegue representar.

Por que esse projeto

A ideia aqui foi bem direta:

• sair da definição teórica
• implementar o aprendizado passo a passo
• visualizar o processo
• entender o limite do modelo na prática

Fechamento

O perceptron é simples — e é justamente por isso que ele é útil.

Ele mostra o começo.

E também deixa claro onde esse começo deixa de ser suficiente.

Código

Você pode encontrar o projeto completo aqui.

A notação assintótica ($O(n)$, $O(n\log\,n)$, $O(n^2)$) descreve crescimento.

Mas não descreve como o código realmente se comporta na CPU.

Dois algoritmos com a mesma complexidade podem ter desempenhos completamente diferentes dependendo de:

• padrão de acesso à memória
• branch prediction
• hierarquia de cache (L1/L2/L3)
• alocação dinâmica
• chamadas de função

Aqui entra o perf.

O objetivo

A pergunta é simples:

Se a complexidade já descreve tudo, por que o comportamento real na CPU muda tanto?

Ferramenta usada: perf

O perf permite observar o que realmente acontece no hardware:

• ciclos de CPU
• instruções executadas
• IPC (instructions per cycle)
• branch misses
• hotspots por função

Isso transforma a análise de teórica para física.

Ambiente de execução

• CPU: AMD Ryzen 7 5825U (8 cores / 16 threads)
• RAM: 7.2 GiB
• Sistema: Debian GNU/Linux 12 (Bookworm)
• Arquitetura: x86-64
• Compilador: GCC com otimização -O2
• Flags: -O2 -Wall -Werror -g

Algoritmos analisados

• Bubble Sort
• Optimized Bubble Sort
• Insertion Sort
• Selection Sort
• Merge Sort
• Quick Sort

Todos executados sobre o mesmo conjunto de entrada.

Métricas analisadas

O perf stat foi usado com:

cycles
instructions
branch-misses

E o perfil detalhado via perf record + perf report.

Visão geral dos resultados

IPC (Instructions per Cycle)

Algoritmos eficientes:

• Quick Sort $\to$ IPC mais baixo, mas execução rápida
• Merge Sort $\to$ IPC moderado e estável

Algoritmos $O(n²)$:

• Bubble / Selection / Insertion Sort $\to$ IPC variável, sem relação direta com eficiência

Importante: IPC alto não significa desempenho melhor. Ele só indica eficiência de pipeline.

Cache e memória

Merge Sort

• padrão de acesso sequencial
• boa localidade de cache
• uso intenso de memcpy/memmove

Resultado:

• bom comportamento em cache
• custo relevante de memória, não de CPU pura

Quick Sort

• melhor desempenho geral
• comportamento depende da partição
• acesso menos previsível à memória

Apesar disso:

• baixa sobrecarga estrutural
• boa performance média em dados aleatórios

Bubble / Selection / Insertion Sort

• muitas comparações repetidas
• reuso intenso das mesmas regiões de memória
• pouca exploração eficiente de cache

Resultado:

• desperdício de ciclos
• baixa eficiência global
• crescimento explosivo com $n$

Branch prediction

Algoritmos com muitos condicionais:

• Quick Sort (partition)
• Bubble Sort (comparações constantes)

sofrem com:

• branch misprediction
• pipeline flush

Isso aparece diretamente no branch-misses.

Hotspots reais (perf report)

Os principais pontos de execução:

• merge
• partition
• insertionSort
• bubbleSort

Em alguns casos:

mais de 90% do tempo fica concentrado em uma única função

Conclusão direta:

desempenho é sempre concentrado, nunca distribuído

O que os dados mostram

Mesmo com a mesma complexidade:

• algoritmos se comportam diferente no hardware
• memória pode dominar o custo total
• chamadas internas podem ser gargalo dominante

Complexidade vs realidade

A teoria responde:

quanto o algoritmo cresce

A CPU responde:

onde o tempo realmente está sendo gasto

Resultados com perf

Merge Sort

• Tempo: ~23 ms
• IPC: 1.21
• Branch misses: 7.80%
• Cycles: 92.4M

Hotspots:

• merge → 73.69%
• memmove → 9.24%
• malloc/free → relevante

comportamento dominado por memória

Quick Sort

• Tempo: ~16 ms
• IPC: 0.90
• Branch misses: 12.54%
• Cycles: 66.5M

Hotspots:

• partition → 88.55%

gargalo: previsibilidade de branches

Insertion Sort

• Tempo: ~3.34 s
• IPC: 4.77
• Branch misses: ~0%

Hotspot:

• insertionSort → 99.95%

simples, mas extremamente ineficiente em escala

Selection Sort

• Tempo: ~10.5 s
• IPC: 4.90
• Branch misses: ~0.01%

Hotspot:

• selectionSort → 99.97%

custo puramente $O(n²)$

Bubble Sort

• Tempo: ~99 s
• IPC: 0.41
• Branch misses: 12.70%

Hotspot:

• bubbleSort → 99.99%

pior cenário clássico confirmado na prática

Optimized Bubble Sort

• Tempo: ~98 s
• IPC: 0.44
• Branch misses: 12.71%

Hotspot:

• optimizedBubbleSort → 99.99%

otimização local irrelevante em termos assintóticos

Leitura geral dos dados

Algoritmos $O(n\log\,n)$

• melhor desempenho absoluto
• melhor uso de CPU
• melhor escalabilidade

Algoritmos $O(n²)$

• crescimento dominante
• IPC não salva performance
• custo explode rapidamente

O ponto mais importante

A diferença real não é só a complexidade:

• Quick Sort $\to$ sensível a branch prediction
• Merge Sort $\to$ sensível a memória
• Bubble/Selection Sort $\to$ redundância extrema

Cada algoritmo falha por um motivo diferente no hardware.

Conclusão

A complexidade continua correta.

Mas incompleta.

Na prática:

• cache muda o jogo
• memória domina muitos algoritmos
• branch prediction altera o desempenho real
• IPC revela eficiência interna

Síntese final

Dois algoritmos podem ter a mesma complexidade e comportamentos completamente diferentes na CPU.

Leitura complementar

Uma análise complementar explora o comportamento estatístico dos algoritmos de ordenação com múltiplas execuções, medindo variabilidade, desvio padrão e consistência dos tempos de execução. Você pode encontrá-la aqui.

Código

Você pode encontrar o projeto completo aqui.

Bubble Sort, Insertion Sort, Selection Sort, Quick Sort e Merge Sort aparecem em introdução à computação.

Alguns deles são simples. Outros são eficientes $O(n^2)\; \text{vs}\; O(n\log n)$.

Beleza. Isso quase todo mundo já viu. Mas isso normalmente fica só na teoria.

Aqui a ideia foi ir além:

colocar todos sob as mesmas condições e observar o comportamento real de execução

Como montei o experimento

Nada muito “acadêmico”, mas com controle suficiente pra não distorcer os resultados:

• todos os algoritmos recebem os mesmos dados
• cada execução é isolada
• medição com clock_gettime usando CLOCK_MONOTONIC
• múltiplas execuções por entrada para reduzir ruído estatístico
• uso de média, desvio padrão e coeficiente de variação (CV)

O coeficiente de variação (CV) — $\text{CV}=\frac{\sigma}{\mu}\times 100$ — é importante porque normaliza a dispersão em relação à média:

ele mostra o quanto o tempo oscila proporcionalmente ao valor médio

• $\sigma \to \text{desvio padrão}$
• $\mu \to \text{média}$

Isso evita uma armadilha comum: desvio padrão parecer “grande” só porque o tempo médio também cresceu.

Benchmark

Cada algoritmo não roda apenas uma vez.

O processo é:

1. o array original é gerado
2. são criadas 100 execuções independentes
3. cada execução ordena uma cópia dos dados
4. calcula-se média, desvio padrão e coeficiente de variação (CV) do tempo

Isso reduz ruído e melhora confiabilidade da medição.

Geração dos dados

Os valores são gerados aleatoriamente no intervalo: [-1e6, 1e6]

E copiados para todos os algoritmos, garantindo:

• mesma distribuição
• mesma dificuldade
• comparação justa

Ambiente de execução

• CPU: AMD Ryzen 7 5825U (8 cores / 16 threads)
• RAM: 7.2 GiB
• Sistema: Debian GNU/Linux 12 (Bookworm)
• Arquitetura: x86-64
• Compilador: GCC com otimização -O2
• Flags: -O2 -Wall -Werror -fsanitize=address -g

Isso é necessário deixar claro, o tempo depende e varia de máquina para máquina.

Escalabilidade

Em entradas pequenas:

• tudo parece semelhante

Mas quando o tamanho cresce:

a complexidade domina completamente o comportamento

Resultados experimentais

Os resultados foram analisados sob três métricas principais:

• média do tempo de execução
• desvio padrão entre execuções
• coeficiente de variação (CV)

Essas métricas permitem avaliar não só o desempenho médio dos algoritmos, mas também a estabilidade das medições e a variabilidade relativa dos tempos.

Gráficos de análise

Para os gráficos abaixo, os algoritmos $O(n^2)$ foram executados com os tamanhos de entrada: 10000, 20000, 50000, 100000 e 200000. Já os algoritmos $O(n \log n)$ foram executados com os tamanhos: 10000, 20000, 50000, 100000, 200000, 500000 e 1000000.

Gráfico 1 — Tempo médio vs tamanho da entrada

Tempo médio para evidenciar crescimento assintótico

Neste gráfico, é possível observar claramente a diferença de escalabilidade entre os algoritmos.

Merge Sort e Quick Sort apresentam crescimento significativamente mais lento, mantendo tempos baixos mesmo com o aumento do tamanho da entrada, o que está em linha com a complexidade $O(n\log\,n)$.

Por outro lado, Bubble Sort e Optimized Bubble Sort exibem crescimento acentuado, característico de algoritmos $O(n^2)$. A otimização aplicada ao Bubble Sort não resulta em ganho relevante de desempenho para entradas grandes, indicando que melhorias locais não alteram o comportamento assintótico do algoritmo.

Além disso, observa-se que o Quick Sort é consistentemente o algoritmo mais rápido entre todos os testados, enquanto os algoritmos quadráticos tornam-se rapidamente inviáveis conforme o tamanho da entrada aumenta.

Gráfico 2 — Desvio padrão vs tamanho da entrada

Variabilidade dos tempos de execução conforme o tamanho da entrada

Neste gráfico, observa-se o comportamento da variabilidade dos tempos de execução à medida que o tamanho da entrada aumenta.

Algoritmos como Merge Sort e Quick Sort apresentam uma tendência de estabilização do desvio padrão, indicando maior consistência nas execuções mesmo para entradas maiores. Isso sugere que, além de eficientes, esses algoritmos são também mais previsíveis.

Por outro lado, algoritmos quadráticos como Bubble Sort, Optimized Bubble Sort, Insertion Sort e Selection Sort exibem maior instabilidade, com picos mais elevados de desvio padrão e crescimento mais acentuado à medida que o tamanho da entrada aumenta.

Esse comportamento indica que, além de mais lentos, esses algoritmos também são menos consistentes, sofrendo maior influência de fatores como distribuição dos dados, cache e variações de execução.

Gráfico 3 — Coeficiente de variação (CV) vs tamanho da entrada

Relação entre dispersão e média dos tempos de execução

Neste gráfico, observa-se a relação entre a variabilidade e o tempo médio de execução dos algoritmos.

Merge Sort e Quick Sort apresentam valores baixos e relativamente estáveis, indicando comportamento consistente mesmo com o aumento do tamanho da entrada.

Por outro lado, os algoritmos quadráticos exibem maior variação relativa, especialmente em entradas maiores, evidenciando menor previsibilidade.

Gráfico 4 — Comparação empírica com complexidade assintótica

Comparação entre tempos reais e curvas teóricas $O(n²)$ e $O(n\log\,n)$

Neste gráfico, as curvas teóricas $O(n^2)$ e $O(n \log n)$ são ajustadas aos dados experimentais, permitindo a comparação direta entre comportamento real e crescimento assintótico.

Observa-se que o Bubble Sort acompanha de forma consistente a curva quadrática, apresentando crescimento mais acentuado à medida que o tamanho da entrada aumenta.

Já o Quick Sort segue de perto a curva $O(n\log\,n)$, mantendo crescimento significativamente mais controlado.

Essa correspondência evidencia que, apesar de abstrair constantes e detalhes de implementação, a análise assintótica descreve corretamente o comportamento dominante dos algoritmos na prática.

Quando algoritmos deixam de ser opção

Algoritmos $O(n^2)$:

• crescem rapidamente
• tornam-se inviáveis em grandes entradas
• deixam de ser práticos muito cedo

Já $O(n \log n)$:

• escalam muito melhor
• continuam eficientes em grandes volumes

O que fica evidente

• a teoria aparece no comportamento
• diferenças pequenas viram enormes
• o crescimento domina completamente o tempo de execução

Síntese dos resultados

Quando os gráficos são vistos em conjunto:

• o tempo médio mostra o custo real
• o desvio padrão mostra estabilidade
• o CV mostra consistência relativa
• a escala logarítmica revela padrões de crescimento
• a comparação teórica valida o modelo matemático

Fechamento

A teoria não é uma abstração aqui — ela aparece nos dados.

Quando se mede corretamente:

complexidade deixa de ser notação e vira comportamento observável

Leitura complementar

Uma análise complementar aprofunda o comportamento interno dos algoritmos a nível de CPU, utilizando perf para investigar IPC, cache hierarchy e branch prediction. Você pode encontrá-la aqui.

Código

Você pode encontrar o projeto completo aqui.

Esse projeto surgiu como uma tentativa de sair do código isolado e entrar em algo mais próximo de uma aplicação de verdade.

A ideia foi simples:

permitir que dados sejam criados, modificados e mantidos ao longo do tempo

No caso, tarefas.

Interface

A interface é direta, sem abstrações pesadas.

Isso deixa claro o fluxo completo:
entrada → processamento → persistência → retorno.

Mais do que CRUD

Na superfície, é um CRUD clássico:

• criar
• visualizar
• atualizar
• remover

Mas o interessante não é isso.

É o ciclo:

• o usuário interage com a interface
• os dados são enviados
• o estado é atualizado
• a persistência garante que nada se perca

Mesmo sendo simples, já forma um sistema completo.

Visualização das tarefas

Aqui fica mais claro como os dados circulam.

Você cria, altera, remove — e o sistema precisa manter tudo consistente.

Onde as coisas se conectam

Diferente de programas locais, aqui existem camadas:

• interface (HTML/CSS)
• lógica (JavaScript)
• servidor
• banco de dados

Nada muito complexo isoladamente.

Mas o sistema depende de tudo isso funcionando junto.

Persistência muda o jogo

Usar um banco de dados adiciona um ponto importante:

os dados deixam de existir só na memória

Eles passam a ter continuidade.

Isso exige:

• consistência nas operações
• cuidado com atualização e remoção
• atenção ao fluxo entre cliente e servidor

Limitações (intencionais)

O projeto não tenta ser um sistema completo.

• sem autenticação
• backend simples
• modelo direto

A ideia não era escalar — era entender o fluxo.

O que esse projeto representa

Ele marca uma transição importante:

de programas isolados
para aplicações com:

• múltiplas camadas
• estado persistente
• interação contínua

Fechamento

No fim, o sistema é simples.

Mas já exige algo além de código que “funciona”:

exige manter consistência ao longo do tempo

E isso muda completamente o tipo de problema.

Código

Você pode encontrar o projeto completo aqui.

Esse projeto começou com uma ideia simples:

fazer dois programas conversarem

Mas rapidamente isso evolui.

Porque no momento em que você sai de um cliente único e entra em múltiplos clientes, o problema muda completamente.

Não é só conexão

Abrir um socket e trocar dados é direto.

O problema real começa quando você precisa lidar com:

• múltiplas conexões ao mesmo tempo
• diferentes tipos de requisição
• respostas consistentes para cada cliente

Aqui já não é mais só comunicação — é organização.

Um servidor, várias responsabilidades

O servidor centraliza tudo.

Ele precisa:

• aceitar conexões
• interpretar o que o cliente quer
• decidir qual funcionalidade executar
• responder corretamente

E tudo isso sem “misturar” os clientes.

Tipos de interação

As funcionalidades em si são simples, mas ajudam a exercitar diferentes cenários:

• responder informações (curiosidades)
• gerar dados em tempo real (hora do servidor)
• enviar arquivos
• listar conteúdo disponível

Cada uma dessas ações exige um tipo diferente de tratamento.

Onde começa a complicar

Quando vários clientes entram ao mesmo tempo, aparecem questões que não existem em programas locais:

• concorrência
• ordem de execução
• consistência das respostas
• tratamento de erro em rede

Nada disso aparece se você testa com um único cliente.

Um detalhe importante

A comunicação aqui não é só envio de dados.

Existe um “protocolo implícito”:

o cliente precisa saber o que pode pedir o servidor precisa entender o que foi pedido

Mesmo que simples, isso já é uma forma de contrato.

O que esse projeto mostra

Ele não tenta ser um servidor completo.

Mas já mostra bem a transição de:

• execução local
• para comunicação entre processos
• para sistemas com múltiplos pontos interagindo

E isso muda completamente o tipo de problema.

Limitações

Algumas coisas ficaram de fora — propositalmente:

• autenticação
• criptografia
• controle mais sofisticado de concorrência

A ideia aqui não foi robustez total, e sim entender o funcionamento.

Fechamento

No fim, o projeto começa simples — abrir conexão, trocar dados.

Mas rapidamente revela algo maior:

quando múltiplos agentes começam a interagir, organizar a comunicação passa a ser o problema central

E isso já é o começo de pensar em sistemas distribuídos.

Código

Você pode encontrar o projeto completo aqui.

Heap Sort e Insertion Sort aparecem em muitos cursos básicos.

Um é eficiente, outro é simples. $O(nlog\,n)\; \text{vs}\; O(n²)$.

Beleza. Isso é o esperado.

Mas esse tipo de comparação costuma parar na teoria. Aqui a ideia foi empurrar um pouco além:

colocar os dois sob as mesmas condições e observar o que acontece de verdade

Como montei o experimento

Nada muito elaborado — mas com cuidado suficiente pra não enviesar o resultado:

• os dois algoritmos recebem exatamente os mesmos dados
• cada um roda isoladamente
• medição com clock_gettime usando CLOCK_MONOTONIC
• foco direto em tempo de execução

A intenção não foi fazer benchmark acadêmico, mas também não deixar solto.

Estruturas

Cada algoritmo roda na sua própria estrutura, bem direta:

• Heap Sort com heap em array
• Insertion Sort com array dinâmico

Isso evita interferência entre implementações e mantém a comparação limpa.

Ambiente de execução

Os testes foram executados no meu notebook:

• CPU: AMD Ryzen 7 5825U (8 cores / 16 threads)
• RAM: 7.2 GiB
• Sistema: Debian GNU/Linux 12 (Bookworm)
• Arquitetura: x86-64
• Armazenamento: SSD
• Compilador: GCC
• Flags: -O2 -Wall -Werror

Isso é importante, dado que o tempo de execução não é absoluto, dependendo diretamente da máquina em que você roda.

O que aparece quando se começa a escalar

Com entradas pequenas, os dois algoritmos convivem bem.

O Insertion Sort até se mantém competitivo — o que faz sentido, já que ele tem baixo overhead.

Mas conforme o tamanho cresce, a diferença deixa de ser sutil.

Ela começa a ficar estrutural.

Gráficos de comparação

• Gráfico 1

Heap Sort — crescimento do tempo de execução

O crescimento é consistente. Nada surpreendente — mas também nada fora de controle.

• Gráfico 2

Insertion Sort — crescimento acelerado do tempo

O crescimento começa aceitável, mas rapidamente perde controle. O comportamento quadrático aparece sem disfarce.

• Gráfico 3

Heap Sort vs Insertion Sort — diferença de crescimento

Colocados lado a lado, não é mais uma questão de “qual é melhor”.

É uma questão de qual continua sendo viável.

O ponto em que a teoria vira limite real

Teve um momento no experimento que deixou isso bem claro.

Ao tentar escalar para 50 milhões de elementos, o Insertion Sort simplesmente deixou de ser uma opção prática.

Não por detalhe de implementação, mas por natureza do algoritmo.

$(5 \times 10^7)^2 = 2.5 \times 10^{15}$, esse seria o número total de operações a serem realizadas.

Mesmo com operações rápidas, isso escala para tempos absurdos.

É aqui que $O(n²)$ deixa de ser só uma notação e vira uma barreira concreta.

O que ficou mais evidente

Algumas coisas que já eram conhecidas ficam bem mais claras após a medição:

• Heap Sort mantém crescimento controlado
• Insertion Sort degrada rápido com escala
• a diferença não é só teórica — é operacional
• viabilidade depende diretamente da complexidade

E talvez o mais importante:

existe um ponto onde o algoritmo deixa de ser “lento” e passa a ser simplesmente inviável

Fechamento

Esse projeto não tenta reinventar nada.

Ele só coloca dois algoritmos clássicos no mesmo cenário e observa o comportamento com dados reais.

E quando você faz isso, a diferença entre eles deixa de ser um detalhe acadêmico.

Vira uma decisão prática.

Código

Você pode encontrar o projeto completo aqui.

Insertion Sort é um dos algoritmos com os quais logo se tem contato na ciência da computação ou cursos correlatos.

Simples, direto, quase intuitivo. Você percorre o array e vai inserindo cada elemento na posição correta.

Então a motivação aqui não foi “entender como funciona”.

Foi outra:

sair do nível teórico e observar o comportamento quando você mede de verdade

Implementar é o básico

A implementação segue o caminho esperado:

• array dinâmico para armazenar os dados
• percurso sequencial
• inserção na parte já ordenada
• ordenação in-place

Nada além do necessário.

E isso é intencional — quanto mais simples a base, mais claro fica o comportamento do algoritmo.

Onde começa a ficar interessante

A diferença aqui foi tratar a medição como parte central.

Usei clock_gettime com CLOCK_MONOTONIC para capturar tempo de execução real.

Porque dizer que o algoritmo é $O(n^2)$ é fácil.

o que importa é ver o que isso significa quando você roda de fato

O que acontece na medição

Com poucos elementos, o algoritmo é rápido.

Direto, eficiente, sem overhead.

Mas conforme o volume cresce, o comportamento começa a se acumular:

• cada inserção passa a custar mais
• mais elementos precisam ser deslocados
• o tempo total cresce de forma agressiva

Nada disso é surpresa — mas ver acontecendo é diferente.

Gráfico

Insertion Sort — crescimento acelerado do tempo

O gráfico deixa isso bem claro.

O crescimento começa controlado, mas rapidamente foge de escala.

É o $n^2$ aparecendo sem suavização.

Um detalhe que chama atenção

O custo do algoritmo não está distribuído de forma uniforme.

Ele se acumula nas inserções.

Quanto mais o array cresce, mais caro fica manter a ordenação incremental.

E isso cria um efeito cascata que domina o tempo total.

Limitações

A medição aqui não tenta ser rigorosa ao extremo:

• uma execução por cenário
• dados gerados de forma simples
• sem análise estatística aprofundada

Não é benchmark formal.

Mas também não precisa ser pra mostrar o comportamento.

Por que esse projeto existe

Esse projeto não é sobre o algoritmo em si.

É sobre observar o limite dele.

Porque enquanto o Insertion Sort funciona muito bem em cenários pequenos ou parcialmente ordenados, ele tem um ponto claro onde deixa de ser viável.

Fechamento

Insertion Sort é simples — e essa simplicidade é exatamente o que o torna útil em certos contextos.

Mas ela também impõe um limite.

Quando você mede, esse limite deixa de ser teórico e vira algo concreto.

E isso muda completamente a forma como você enxerga o algoritmo.

Código

Você pode encontrar o projeto completo aqui.

Tabela hash normalmente começa com uma decisão fixa: você define uma função e trabalha em cima dela.

Aqui eu quis fazer um pequeno desvio desse padrão — não mudando a estrutura, mas a forma de escolher a função.

A motivação foi simples: antes de aplicar a função, olhar minimamente para os dados.

O método

A abordagem usada aqui não é nova.

Ela segue uma linha conhecida em hashing: usar propriedades da distribuição das chaves para tentar escolher uma função que se comporte melhor naquele contexto.

No caso, a escolha foi trabalhar com análise de dígitos:

• decompor os números em dígitos
• observar a frequência de cada dígito por posição
• comparar com uma distribuição ideal (uniforme)
• escolher a posição mais “equilibrada”

Isso gera um critério simples: usar o dígito menos enviesado como base para o índice.

Não é uma função universal, nem perfeita — é uma heurística baseada no conjunto de entrada.

Por que isso faz sentido

Nem todo dígito carrega a mesma informação.

Dependendo do conjunto, alguns dígitos são praticamente inúteis (muito repetidos), enquanto outros distribuem melhor.

A ideia é justamente evitar escolhas ruins logo de cara.

Em vez de usar, por exemplo, sempre o último dígito, deixar os dados indicarem qual posição tende a espalhar melhor os valores.

O que muda na prática

A função final continua simples:

index = digit % capacity;

Nada sofisticado.

A diferença é que o digit não é fixo — ele é escolhido com base em uma análise prévia.

Isso mantém a implementação leve, mas introduz um pequeno grau de adaptação.

Limitações

Esse tipo de abordagem tem limites claros:

• depende completamente do conjunto inicial
• não reage a mudanças depois
• o critério de “melhor distribuição” é aproximado
• não substitui funções de hash mais robustas

Ou seja, não é solução geral — é uma variação pontual.

Por que explorar isso

O objetivo aqui não foi propor algo novo, mas tornar explícita uma ideia que normalmente fica implícita:

a escolha da função de hash pode (e talvez devesse) considerar os dados

Mesmo que de forma simples.

Implementar isso em C, de maneira direta, foi mais um exercício de exploração do que de otimização.

Fechamento

Esse projeto fica num meio-termo interessante:

não muda a estrutura clássica, mas também não aceita completamente a rigidez dela.

É só um pequeno ajuste de perspectiva — de função fixa para função influenciada pelos dados.

E às vezes esse tipo de ajuste já abre espaço pra pensar diferente.

Código

Você pode encontrar o projeto completo aqui.

Heap e Heap Sort são estruturas e algoritmos bem estabelecidos, bem documentados e já explorados até o limite.

Então a motivação aqui não foi “entender como funciona”.

Foi outra coisa:

sair do nível teórico e olhar o comportamento real.

Implementar é o básico

A implementação seguiu o caminho padrão:

• max-heap baseada em array
• relações clássicas entre pai e filhos
• construção da heap
• heapify
• ordenação in-place

Nada fora do esperado.

E isso é proposital — quando a base é conhecida, fica mais fácil observar o que realmente interessa depois.

Onde começa a ficar interessante

A diferença aqui foi adicionar medição de tempo de execução usando clock_gettime com CLOCK_MONOTONIC.

Não como detalhe, mas como parte central do projeto.

Porque até então, Heap Sort é só mais um algoritmo com complexidade $O(n \log n)$.

Mas isso, sozinho, não diz muita coisa na prática.

O que acontece quando se mede

Quando você roda o algoritmo com volumes maiores de dados, algumas coisas começam a ficar mais concretas:

• o crescimento do tempo deixa de ser abstrato
• o custo de reorganizar a heap aparece com mais clareza
• o impacto de trabalhar in-place fica evidente

Nada disso contradiz a teoria — mas também não é algo que você “sente” só olhando pra notação assintótica.

Tem uma diferença grande entre saber e observar.

Gráfico

Heap Sort — crescimento do tempo de execução

O comportamento é bem estável.

O tempo cresce, claro, mas de forma controlada — sem aquele salto abrupto que aparece em algoritmos quadráticos.

Um detalhe que chama atenção

Uma coisa que fica clara é como o custo está concentrado.

A construção da heap é relativamente rápida. Mas o processo de extração + heapify repetido é onde o algoritmo realmente “paga o preço”.

É ali que o $\log n$ aparece repetidamente, acumulando custo ao longo da execução.

Limitações

A medição aqui não tenta ser rigorosa ao extremo:

• uma execução por cenário
• dados gerados de forma simples
• sem análise estatística aprofundada

Não é benchmark científico.

Mas também não era essa a intenção.

Por que esse projeto existe

Esse projeto não é sobre reinventar Heap Sort.

É sobre dar um passo além do “funciona” e entrar no “como se comporta”.

Porque em algum momento, só saber a teoria começa a ficar pouco.

Fechamento

No fim, a estrutura e o algoritmo são os mesmos de sempre.

O que muda é a forma de olhar.

Quando você mede, a complexidade deixa de ser só uma ideia e vira algo observável — quase palpável.

E isso, por mais simples que pareça, muda bastante a forma como você enxerga algoritmos clássicos.

Código

Você pode encontrar o projeto completo aqui.

Esse projeto nasceu de uma mudança simples de foco.

Até então, os programas começavam, rodavam e acabavam — tudo existia só durante a execução.

Aqui a ideia foi outra:

manter dados vivos mesmo depois do programa terminar

Isso muda bastante o tipo de problema.

Não é só armazenar — é manter consistência

Gerenciar alunos, por si só, não é complicado:

• cadastrar
• remover
• buscar
• listar

Mas quando você adiciona persistência, entra outra camada:

• o que está em memória precisa refletir o que está em disco
• leitura e escrita precisam ser compatíveis
• qualquer inconsistência quebra tudo silenciosamente

Deixa de ser só manipulação de dados — vira manutenção de estado.

A escolha da estrutura

Usei uma lista duplamente encadeada.

Aqui a escolha foi bem intencional.

Ela não é a mais simples, mas resolve bem algumas operações:

• remoção sem precisar percorrer desde o início
• navegação nos dois sentidos
• inserções mais flexíveis

Para um sistema que sofre alterações frequentes, isso ajuda a manter o comportamento previsível.

Onde o projeto realmente começa

A parte mais interessante não foi a lista.

Foi a persistência em arquivo binário.

Em vez de serializar para texto, a ideia foi trabalhar direto com bytes.

Isso exige mais cuidado:

• definir exatamente o que é escrito
• garantir que a leitura reconstrua corretamente
• lidar com tamanhos variáveis (principalmente strings)

Nada disso é difícil isoladamente — mas tudo precisa bater exatamente.

Um detalhe que faz diferença

Strings não são triviais aqui.

Salvar um inteiro é direto. Salvar uma string exige:

• armazenar o tamanho
• escrever o conteúdo
• reconstruir corretamente depois

Se qualquer parte disso falhar, o dado corrompe.

E não tem aviso.

Quando as coisas começam a se conectar

Esse projeto junta várias camadas que isoladamente são simples:

• memória dinâmica
• estruturas encadeadas
• manipulação de arquivos

Mas juntas, elas exigem mais rigor.

Você precisa garantir:

• alocação correta
• liberação correta
• cópia correta
• leitura e escrita coerentes

Não dá pra “deixar passar”.

O que esse projeto representa

Ele fica num ponto interessante entre exercício e sistema real.

Não é complexo, mas já força a pensar em:

• persistência
• consistência
• organização de dados

Coisas que não aparecem quando tudo vive só em memória.

Fechamento

A principal diferença aqui não está no algoritmo nem na estrutura.

Está no fato de que os dados continuam existindo depois.

E isso muda o tipo de cuidado que o código exige.

Quando você passa a lidar com estado persistente, pequenos erros deixam de ser locais — eles se acumulam.

E é aí que o nível do problema sobe.

Código

Você pode encontrar o projeto completo aqui.