O Modelo Mental do NumPy e pandas

NumPy e pandas são geralmente ensinados como duas bibliotecas separadas com duas APIs separadas, mas por baixo da sintaxe elas compartilham um modelo.

Dados numéricos vivem em arrays contíguos e homogeneamente tipados, e quase toda operação que você escreve é uma solicitação para executar um loop em código compilado em vez do interpretador Python.

Esta página é sobre esse modelo compartilhado - o que vetorização e broadcasting realmente fazem por baixo da sintaxe, como Series, DataFrame e Index do pandas constroem estrutura rotulada sobre os arrays brutos do NumPy, e onde o motor preguiçoso do Polars se desvia completamente desse modelo.

Noções Básicas de Análise de Dados percorre a API concreta para uma primeira análise; esta página é sobre a máquina por baixo dela.

Resumo

• NumPy armazena dados numéricos homogêneos em memória contígua e empurra loops para código compilado (vetorização); pandas adiciona linhas e colunas rotuladas (Series, DataFrame, Index) sobre o mesmo modelo de array, e o alinhamento ocorre por rótulo em vez de posição.
• Por Que Importa: Código que "parece o mesmo" pode se comportar de maneira muito diferente dependendo se ele aciona um ufunc vetorizado, um broadcast, um join alinhado por índice, ou uma materialização completa - ler incorretamente qual deles está acontecendo é a maior fonte de código lento e bugs silenciosos em análise de dados.
• Conceitos Chave: vetorização, broadcasting, dtype, Index e alinhamento, ufunc, avaliação preguiçosa.
• Quando Usar: Qualquer transformação numérica sobre uma coluna ou array, joins/mesclagens com chave em rótulos, agregações que precisam respeitar a identidade da linha, e qualquer ponto onde você esteja decidindo se o modelo ansioso do pandas ou o modelo preguiçoso do Polars se adequam ao tamanho dos seus dados.
• Limitações / Trade-offs: Vetorização e avaliação ansiosa ainda materializam cada resultado intermediário na memória, o alinhamento pode introduzir NaNs silenciosamente quando os índices não correspondem, e nem NumPy nem pandas ansioso planejam com antecedência como um motor preguiçoso faz.
• Tópicos Relacionados: indexação e remodelação de arrays, agregação groupby, ajuste de desempenho e memória, modelo de execução preguiçosa do Polars.

Fundamentos

Um ndarray do NumPy é um bloco de memória contígua contendo valores de um único dtype - todos int64, todos float64, ou todos de algum outro tipo de largura fixa.

Essa homogeneidade é o que torna a vetorização possível: como cada elemento tem o mesmo tipo e tamanho, o NumPy pode entregar o array inteiro para um loop compilado (um ufunc, abreviação de função universal) em vez de pedir ao interpretador Python para visitar cada elemento um de cada vez.

Um loop for Python sobre uma lista tem sobrecarga do interpretador - verificações de tipo, despacho dinâmico, boxing de objetos - em cada iteração; uma chamada vetorizada do NumPy paga essa sobrecarga uma vez, depois executa um loop C apertado sobre bytes brutos.

Broadcasting é a regra que permite que arrays de formas diferentes se combinem sem que você escreva um loop explícito ou cópia: quando as formas não correspondem, o NumPy as compara da dimensão final para dentro, e qualquer dimensão de tamanho 1 é esticada para corresponder à sua contraparte - conceitualmente, não fisicamente, pois nenhuma memória é realmente duplicada.

Uma analogia simples: broadcasting é como entregar o mesmo folheto para cada assento em um estádio sem imprimir um por assento - o conteúdo do folheto é reutilizado, apenas a "posição" muda.

O pandas pega esse modelo de array e adiciona duas coisas que o NumPy não tem: rótulos e heterogeneidade entre colunas.

Uma Series é um array NumPy (ou um array baseado em Arrow) mais um Index - um eixo rotulado que dá a cada elemento uma identidade além de sua posição.

Um DataFrame é melhor entendido como um dicionário de Series que compartilham o mesmo Index de linha, que é por que cada coluna pode ter seu próprio dtype, embora cada valor dentro de uma coluna ainda precise compartilhar um.

Este é o detalhe que confunde os novatos vindos do NumPy: a aritmética e os joins do pandas operam no alinhamento por rótulo primeiro, e a posição é quase incidental.

Mecânicas e Interações

Vetorização e broadcasting explicam por que a matemática do NumPy é rápida, mas as mecânicas interessantes acontecem na fronteira entre "vetorizado" e "não".

Cada chamada de ufunc do NumPy tem que decidir, antes de executar, se as formas das entradas são compatíveis para broadcast; se não forem, você recebe um ValueError, não uma saída incorreta silenciosa, que é uma das melhores propriedades de segurança do modelo.

O pandas adiciona alinhamento sobre isso: somar duas Series primeiro reindexa ambas para a união de seus índices, e qualquer rótulo presente em uma mas não na outra produz NaN em vez de gerar um erro - uma escolha de design que troca segurança por conveniência, e que fabrica silenciosamente dados ausentes se você não esperava uma incompatibilidade.

Essa mesma etapa de alinhamento é também por que uma operação de DataFrame pode ser muito mais lenta do que a operação equivalente de array NumPy bruto nos mesmos dados - os rótulos precisam ser reconciliados a cada vez, não apenas os números.

O layout da memória também importa: arrays NumPy são contíguos e podem ser em ordem de linha (ordem C) ou ordem de coluna (ordem Fortran), e uma operação que caminha contra o grão desse layout paga uma penalidade de localidade de cache, mesmo que o loop vetorizado ainda "funcione".

O gerenciador de blocos interno do pandas historicamente armazenava colunas do mesmo dtype juntas exatamente por esse motivo, e o pandas moderno (2.2+) cada vez mais usa arrays Arrow como base para suas colunas, o que muda a história de valores ausentes: dtypes anuláveis baseados em Arrow carregam um bitmap de validade explícito em vez de depender de NaN, então colunas de inteiros e strings podem conter valores ausentes reais sem fazer upcast para float64 como o pandas clássico baseado em NumPy tinha que fazer.

A indexação é onde as arestas afiadas do modelo aparecem mais: .loc opera no espaço de rótulos, .iloc no espaço posicional, e indexação encadeada (df[df.x > 0]['y'] = 1) pode silenciosamente escrever em uma cópia temporária em vez do frame original, que é o mecanismo por trás de SettingWithCopyWarning.

import numpy as np
 
a = np.array([[1, 2, 3], [4, 5, 6]])   # shape (2, 3)
b = np.array([10, 20, 30])             # shape (3,)
 
# b é transmitido por cada linha: as formas (2,3) e (3,) se alinham na
# dimensão final, então b é conceitualmente repetido para cada linha
result = a + b   # shape (2, 3), nenhum loop explícito, nenhuma cópia de b armazenada

Considerações Avançadas e Aplicações

O modelo de array e alinhamento escala bem até que os dados parem de caber confortavelmente na memória, e é exatamente aí que o design do Polars se afasta dele.

O Polars mantém a mesma ideia de memória colunar baseada em Arrow, mas sua API LazyFrame não executa nada quando você escreve uma transformação - ela constrói um plano de consulta, e apenas collect() aciona a execução.

Esse modelo adiado permite que o otimizador de consulta do Polars empurre filtros e seleções de colunas para baixo antes que qualquer I/O ocorra, então escanear um arquivo Parquet com scan_parquet() e um .filter() pode pular a leitura de grupos de linhas inteiros ou colunas que o plano prova serem desnecessários.

O pandas não tem um estágio de planejamento equivalente: cada chamada de .assign(), .merge(), ou .groupby() executa imediatamente e materializa seu resultado completo, o que é simples de raciocinar, mas significa que um DataFrame intermediário desnecessário ainda é construído, mesmo que um passo posterior descarte a maior parte dele.

O Polars também tem uma API ansiosa que se comporta mais como o pandas - executa imediatamente - mas a API preguiçosa é onde a diferença arquitetural realmente compensa, particularmente em dados grandes demais para conter confortavelmente múltiplas cópias intermediárias.

Nada disso torna o NumPy ou o pandas ansioso obsoletos: para dados que já cabem na memória com um punhado de passos de transformação, um otimizador tem pouco a otimizar, e a simplicidade da execução imediata muitas vezes vale mais do que a sobrecarga do planejamento adiado.

Conceitos Errôneos Comuns

• "pandas é apenas NumPy com rótulos acoplados." - Rótulos mudam a semântica, não apenas a apresentação: a aritmética entre duas Series alinha no Index primeiro, o que pode introduzir NaNs silenciosamente que uma operação NumPy bruta nos mesmos números nunca faria.
• "Código vetorizado é sempre barato em memória." - Vetorização evita sobrecarga do interpretador, não custo de memória; broadcasting um array grande contra outro ainda aloca um array de resultado completo, e operações pandas encadeadas podem cada uma alocar um novo DataFrame intermediário.
• "A API preguiçosa do Polars é sempre mais rápida que a do pandas." - O otimizador ganha seu sustento em varreduras grandes com filtros/projeções para empurrar para baixo; em dados pequenos na memória com algumas operações, a sobrecarga de planejamento pode apagar qualquer vantagem, e collect() ainda tem que rodar eventualmente.
• ".loc e .iloc são basicamente intercambiáveis." - .loc resolve rótulos, .iloc resolve posições inteiras, e em um DataFrame com um Index não padrão ou reordenado, esses dois podem retornar linhas completamente diferentes para o mesmo argumento numérico "idêntico".
• "NaN é como o pandas representa qualquer valor ausente." - O pandas clássico baseado em NumPy só tinha um NaN nativo para floats, o que forçou colunas de inteiros com dados ausentes a fazer upcast para float64; dtypes anuláveis baseados em Arrow no pandas 2.2+ finalmente dão a inteiros e strings um marcador de ausente real sem esse upcast.

FAQs

Relacionados

• Arrays NumPy - criação, dtypes e as mecânicas de broadcasting nas quais esta página se baseia.
• Series e DataFrames pandas - a construção concreta e a API de seleção para o modelo Series/DataFrame/Index.
• Indexação e Remodelação NumPy - views vs cópias e manipulação de forma na prática.
• Polars - o motor preguiçoso baseado em Arrow referenciado em Considerações Avançadas.
• Desempenho e Memória - ajuste concreto uma vez que você sabe qual parte do modelo está custando a você.
• GroupBy e Agregação - split-apply-combine como uma extensão do modelo de alinhamento.

Versões da Pilha: Esta página foi escrita para Python 3.14 (estável) / 3.13 (manutenção), pandas 2.2+, e Polars 1.x.