NumPy

Olá, daqui fala o Alex do DEV STORIES DOT EU. NumPy, episódio 1 de 7. A list standard do Python é altamente flexível, mas no momento em que tentas fazer cálculos com um milhão de itens, bates numa parede de performance. Acabas por pagar um custo enorme com pointers só para multiplicar números. A solução para este bottleneck é o core engine da computação científica em Python: o ndarray. Para perceberes por que o ndarray existe, tens de olhar para o que as lists standard fazem under the hood. Uma list de Python não guarda raw numbers. Guarda pointers. Cada pointer aponta o sistema para uma localização dispersa na memória onde vive um object Python completo. Se escreveres um loop standard para multiplicar duas sequências de um milhão de números, o interpreter de Python tem um trabalho enorme. Para cada item, ele vai buscar o pointer, localiza o object, verifica o seu data type para confirmar se é realmente um número, faz o cálculo matemático e guarda o novo object. Fazer isto um milhão de vezes introduz um overhead severo. Este ciclo de pointer-chasing e type-checking é o motivo pelo qual os loops standard são simplesmente demasiado lentos para grandes operações matemáticas. O ndarray, que significa N-dimensional array, abdica desta flexibilidade em troca de raw speed. A parte N-dimensional significa que este object pode representar uma sequência plana de números, uma grid bidimensional ou uma matriz matemática multidimensional complexa. Independentemente de quantas dimensões definas, under the hood, ele opera com base em duas regras rigorosas. Primeiro, exige data types homogéneos. Cada elemento num ndarray tem de ser exatamente do mesmo tipo, como um float de 64 bits. Segundo, usa um tamanho de memória fixo. Quando crias um ndarray, o NumPy reserva um único bloco contínuo de memória. Não há pointers. Os raw numbers ficam compactados uns ao lado dos outros na memória do sistema. O ponto chave é este. Como o NumPy conhece o data type exato e o memory layout exato, consegue fazer bypass completo ao lento interpreter de Python. Quando multiplicas dois ndarrays com um milhão de números, não escreves um loop. Escreves simplesmente o array A multiplicado pelo array B. Este processo chama-se vectorization. O NumPy recebe o teu comando e delega o cálculo propriamente dito a código C pré-compilado. O código C processa este bloco contínuo de memória a velocidades de hardware. Salta o type-checking e os pointer lookups para itens individuais porque a memória é perfeitamente uniforme. O trade-off para este enorme speed boost é a rigidez estrutural. Como a memória é um bloco contínuo, não podes simplesmente fazer append de um novo número a um ndarray da mesma forma que fazes com uma list de Python. Se precisares de um array maior, o NumPy geralmente tem de alocar um bloco de memória totalmente novo e copiar os dados antigos. Constróis o container com o tamanho exato de que precisas e, em seguida, corres as tuas operações em todo o bloco de uma só vez. A list standard do Python é uma coleção de objects isolados espalhados pela memória. O ndarray do NumPy é um bloco denso e uniforme de raw data, concebido para ser processado instantaneamente por código C otimizado. Se gostas destes episódios e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NumPy, episódio dois de sete. Raramente digitas dados à mão em data science. Em vez disso, precisas de criar vastas grelhas vazias e intervalos numéricos com um único comando. Vamos falar sobre as funções intrínsecas que te permitem criar arrays do zero e controlar a sua estrutura. Primeiro, uma rápida correção sobre a criação manual. Quando convertes uma list standard de Python num array usando a função básica array, um erro comum é passar vários argumentos separados para criar múltiplas dimensões. A função espera uma única sequência. Para criar um array bidimensional, passas uma list que contém outras lists, não duas lists separadas. Cada array que crias carrega metadados estruturais. Duas propriedades são as mais importantes aqui. A primeira é ndim, que te indica o número de eixos, ou dimensões, que o array tem. Uma sequência plana tem um ndim de um, enquanto uma grelha plana tem um ndim de dois. A segunda propriedade é shape. O shape é um tuple de inteiros que indica o tamanho exato do array ao longo de cada dimensão. Se tiveres uma matriz com duas linhas e três colunas, o seu shape é dois por três. O comprimento do tuple shape será sempre igual ao valor de ndim. Criar arrays a partir de lists existentes serve para pequenos testes, mas o trabalho a sério exige a geração programática de arrays. Se precisares de um placeholder para preencher com dados mais tarde, usas as funções zeros ou ones. Basta passares um tuple shape a estas funções, e elas devolvem um array com essa estrutura exata, preenchido inteiramente com zeros ou uns. Por defeito, estas funções criam números de floating-point, mas podes alterar isto especificando um data type diferente. Quando precisas de uma sequência de números, o NumPy oferece duas ferramentas principais. A primeira é o arange, que funciona de forma muito semelhante ao range standard de Python. Dás-lhe um valor inicial, um valor final e um tamanho de step. Ele gera um array de números espaçados por esse step. Embora o arange seja ótimo para inteiros, usá-lo com steps de floating-point pode causar resultados imprevisíveis devido à forma como os computadores lidam com a precisão decimal. O número de elementos que recebes de volta pode variar ligeiramente dependendo de erros de arredondamento microscópicos. Isso leva-nos ao linspace, que resolve o problema da precisão de floating-point. Em vez de definires o tamanho do step, defines o número exato de elementos que queres. Dás ao linspace um valor inicial, um valor final e o número total de pontos. O NumPy calcula o espaçamento exato para ti. Considera um cenário em que estás a avaliar uma função matemática num intervalo específico. Queres calcular a função através de uma grelha suave de coordenadas entre zero e um. Usando o linspace, podes gerar exatamente cem coordenadas uniformemente espaçadas ao longo desse intervalo. Obténs um array unidimensional perfeitamente distribuído, garantindo que tanto o limite inicial como o final estão incluídos. É aqui que fica interessante. A distinção entre estes dois geradores de sequências dita o teu workflow. Usa o arange quando o tamanho exato do step for importante, como contar inteiros de dois em dois, mas usa sempre o linspace ao lidar com floats e intervalos para poderes garantir exatamente quantos data points obténs e atingires precisamente os teus limites. Obrigado por ouvires — até à próxima.

Olá, daqui fala o Alex da DEV STORIES DOT EU. NumPy, episódio 3 de 7. Tens uma matriz com mil milhões de pixels e precisas de inverter as suas linhas e colunas. Se fizeres isto em Python standard, a tua máquina vai parar completamente enquanto copia gigabytes de dados. No NumPy, esta operação acontece instantaneamente. Reordenar esses pixels não move um único byte de memória. Isto acontece devido à forma como o NumPy gere a memória, strides e views under the hood. Para perceberes por que o NumPy é tão rápido, tens de olhar para a estrutura interna de um array. Um array NumPy não é um objeto único e monolítico. É estritamente dividido em duas partes. A primeira parte é o data buffer. Este é um bloco contíguo e flat de raw memory. É apenas uma linha unidimensional de bytes na RAM. O raw buffer não sabe absolutamente nada sobre linhas, colunas ou dimensões. A segunda parte são os metadados. Este é um pequeno header, implementado internamente como uma estrutura em C, que diz ao NumPy como interpretar essa linha raw de bytes. Os metadados guardam um pointer para o início do data buffer, o data type, a shape do array e os strides. Os strides são o mecanismo que transforma uma linha flat de memória numa grid multidimensional. Um stride é simplesmente o número de bytes que o computador tem de avançar na memória para encontrar o próximo elemento ao longo de um eixo específico. Supõe que tens um array bidimensional de inteiros de 64 bits. Cada inteiro ocupa oito bytes. Para mover uma coluna para a direita, o stride pode ser de oito bytes. Mas para descer para a próxima linha, o stride pode ser de oitenta bytes, porque tem de saltar uma linha inteira de dados no raw buffer para encontrar o início da próxima. Muitos developers assumem que, quando fazes um slice de um array, o sistema aloca nova memória e copia os dados selecionados. Isso é incorreto. Quando pedes um slice, o NumPy deixa o raw data buffer completamente intacto. Em vez disso, cria um novo header de metadados. Este novo header aponta exatamente para o mesmo bloco de memória, mas altera o pointer inicial e modifica os strides para saltar os elementos que excluíste. A isto chama-se uma view. Aqui está o ponto-chave. Como os raw data e os metadados são mantidos separados, as operações que alteram a shape ou a ordem do array são quase completamente gratuitas. Lembra-te da transposição daquela enorme matriz de mil milhões de pixels. O NumPy não pega nos dados e os reorganiza fisicamente. Simplesmente troca os valores de stride no novo header de metadados. O número de bytes que usavas para saltar para a próxima linha passa a ser o número que saltas para encontrar a próxima coluna. Uma estrutura de array completamente diferente é devolvida ao teu código, mas é apenas uma view a olhar exatamente para a mesma memória física. Esta separação é a base da eficiência de memória do NumPy. Podes dividir um dataset enorme em dezenas de slices sobrepostos, passá-los para diferentes funções e consumir zero memória extra para os dados em si. Estás apenas a gerar pequenos headers de metadados. No entanto, isto significa que partilhas state. Modificar um valor num slice vai alterar o array original, porque existe apenas um verdadeiro data buffer por baixo de todos eles. A separação dos raw bytes das regras que os governam significa que as tuas transformações de dados mais pesadas são muitas vezes apenas trocas leves de metadados. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex do DEV STORIES DOT EU. NumPy, episódio 4 de 7. Se alguma vez deres por ti a escrever um for-loop para multiplicar números num array, para. Fazer isso significa que estás a pagar o overhead do interpreter de Python em cada um dos itens, e o teu código está a correr cem vezes mais devagar do que o necessário. A solução é usar universal functions para fazer cálculos matemáticos sem loops. Um erro comum é tentar passar um array inteiro para uma função do standard math module de Python. Se passares um milhão de leituras de sensores para math ponto sine, o Python dá um erro. O standard math module só entende valores scalar únicos. Para processar um array, normalmente terias de escrever um loop. Mas Python é uma linguagem dinâmica. Dentro de um loop, o interpreter avalia o data type em cada iteration antes de calcular o resultado. Quando processas datasets massivos, essas pequenas pausas de type-checking acumulam-se e representam um performance bottleneck significativo. Uma universal function, ou ufunc, resolve isto ao operar em arrays elemento a elemento automaticamente. Quando chamas uma ufunc, o NumPy empurra a execução do loop para código C compilado. Como os arrays de NumPy têm um único data type uniforme, o código C não precisa de fazer pausas e verificar os tipos. Ele itera sobre blocos contíguos de memória e calcula o resultado tão rápido quanto o teu processador permitir. Vejamos um cenário concreto. Tens um array com milhares de leituras de sensores ambientais e precisas de aplicar uma transformação matemática a todas elas de uma só vez. Em vez de escreveres um loop, simplesmente passas o array inteiro para uma universal function como numpy ponto exp ou numpy ponto sin. A ufunc recebe o teu input array, corre o loop rápido ao nível de C em cada um dos elementos, e devolve um array completamente novo preenchido com as leituras transformadas. Esta é a parte que interessa. As ufuncs fazem mais do que apenas transformações elemento a elemento. Elas contêm built-in methods para colapsar dados, fazendo um bypass completo ao Python para agregações. O mais comum é o método reduce. Supõe que aplicaste a tua transformação matemática, e agora precisas da soma total de todo o array. Chamas o método reduce diretamente na ufunc de adição. Escreves numpy ponto add ponto reduce, e passas-lhe o teu array. O método reduce aplica a operação de adição subjacente aos dois primeiros elementos. Ele pega nessa soma, adiciona-a ao terceiro elemento, e continua este padrão até que todo o array seja colapsado num único valor scalar. Se os teus dados tiverem múltiplas dimensões, podes controlar como este colapso acontece. Se as leituras dos teus sensores formarem uma grid bidimensional, onde as linhas são diferentes sensores e as colunas são timestamps individuais, reduzir a grid inteira a um único número destrói essa estrutura. Ao fornecer um argumento axis, controlas a direção da operação. Se disseres ao método reduce para operar ao longo do axis zero, ele colapsa as linhas, deixando-te com um array com a soma de todos os sensores em cada timestamp individual. Sempre que deixas uma universal function lidar com a iteration nativamente, estás a trocar loops lentos de Python por uma execução em C otimizada para hardware. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex do DEV STORIES DOT EU. NumPy, episódio 5 de 7. O que acontece quando tentas multiplicar uma matriz tridimensional de um milhão de píxeis por um pequeno array de três números? Em muitas linguagens estritas, recebes um erro de incompatibilidade de shape. No NumPy, simplesmente funciona. Este comportamento chama-se broadcasting. O broadcasting descreve como o NumPy lida com arrays com shapes diferentes durante operações aritméticas. Ele pega no array mais pequeno e, conceptualmente, estica-o sobre o maior para que os seus shapes se alinhem perfeitamente. Muitas vezes, os ouvintes acreditam erradamente que este esticamento copia fisicamente os dados para construir um novo array correspondente em memória. Não é o caso. O NumPy lida com este alinhamento implicitamente ao nível do C. Ele itera sobre os mesmos elementos várias vezes com zero memory overhead, o que torna o broadcasting incrivelmente rápido e altamente eficiente. Para o usares, tens de perceber como o NumPy decide se dois arrays são compatíveis. Ele não olha para o número total de elementos. Olha para os tuples de shape. O NumPy alinha os shapes dos dois arrays e compara-os começando pelas trailing dimensions — as da extrema direita — e avança para a esquerda. Duas dimensões são compatíveis se cumprirem uma de duas condições estritas. Têm de ser exatamente iguais, ou uma delas tem de ser o número um. Se nenhuma das condições for cumprida em qualquer ponto durante a comparação, o NumPy lança um ValueError e a operação falha. Vamos aplicar isto a um cenário concreto. Estás a trabalhar com uma imagem RGB. Carregas a imagem para um array NumPy com um shape de 256 por 256 por 3. O 3 representa os canais de cor vermelho, verde e azul no final do shape. Agora, precisas de fazer a correção de cor desta imagem, ajustando a escala de cada canal de cor de forma diferente. Defines um array unidimensional que contém três pesos de correção de cor. O shape deste array é apenas 3. Quando multiplicas o enorme array da imagem pelo pequeno array de pesos, o NumPy aplica a regra da direita para a esquerda. Ele coloca o shape da imagem, 256 por 256 por 3, por cima do shape dos pesos, que é apenas 3. Começando na extrema direita, as trailing dimensions são comparadas. Ambas são 3. Como são iguais, são compatíveis. A seguir, o NumPy move-se para a esquerda. O array da imagem tem uma dimensão de 256, mas o array dos pesos ficou totalmente sem dimensões. É aqui que a segunda parte da regra entra em ação. Quando um array tem menos dimensões do que o outro, o NumPy implicitamente adiciona uns ao início do seu shape até que coincidam em comprimento. O shape do array dos pesos é tratado como 1 por 1 por 3. Agora a comparação continua. A imagem tem uma dimensão de 256, e o array dos pesos tem agora uma dimensão de 1. Como uma delas é um 1, são compatíveis. O array dos pesos é conceptualmente esticado ao longo das 256 linhas. Isto acontece novamente para a dimensão seguinte. Os shapes alinham-se, e o NumPy aplica os teus três pesos de cor por todos os sessenta e cinco mil píxeis de forma perfeita. Esta é a parte que interessa. A regra só funciona da direita para a esquerda. Se tiveres um array bidimensional com um shape de 5 por 4, e tentares adicionar um array de shape 5, podes pensar que ele se vai esticar ao longo das colunas. Não vai. Começando pela direita, o NumPy compara 4 e 5. Não são iguais, e nenhum deles é um. A operação falha instantaneamente. Para que funcione, terias de fazer um reshape ao segundo array para 5 por 1 primeiro. O broadcasting permite-te escrever código limpo e sem loops, que é executado a velocidades de código compilado. A regra de ouro é sempre as trailing dimensions primeiro: têm de corresponder exatamente, ou uma delas tem de ser um. Obrigado por ouvires. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NumPy, episódio 6 de 7. Ir buscar todos os números negativos a um array com mil milhões de itens não é um problema de pesquisa. Não deve exigir um loop, e certamente não deve tornar a tua aplicação mais lenta. É aqui que usamos filtragem de precisão: boolean masking. O slicing básico vai buscar blocos de dados organizados e previsíveis. Mas os dados do mundo real são caóticos. Raramente queres apenas os primeiros dez itens. Queres elementos específicos com base numa condição lógica, e esses elementos podem estar espalhados aleatoriamente por todo o teu dataset. No NumPy, ir buscar dados desta forma chama-se advanced indexing, e o boolean masking é uma das suas formas mais poderosas. Imagina um array enorme de leituras de temperatura. Precisas de isolar apenas os valores que descem abaixo de zero. Em vez de escreveres um loop para verificar cada uma das leituras, usas uma mask. Uma mask é um array de valores booleanos, ou seja, True ou False. Crucialmente, este array booleano tem exatamente o mesmo shape que o teu array de dados original. Crias a mask aplicando uma condição de menor que zero diretamente ao array. O NumPy avalia instantaneamente cada elemento. Se uma temperatura for inferior a zero, a mask regista um True nessa posição exata. Se a temperatura for igual ou superior a zero, regista um False. Assim que tiveres esta mask, aplicas a mask de volta ao array original, passando-a exatamente onde normalmente colocarias um index. O NumPy lê a mask, seleciona cada elemento onde a mask é True, e descarta o resto. A operação resulta num array unidimensional totalmente novo, contendo apenas as tuas temperaturas negativas. Tudo acontece numa única etapa, executada em código C altamente otimizado nos bastidores. Presta atenção a esta próxima distinção, porque confunde muitos developers. Precisas de saber exatamente o que o NumPy te devolve quando filtras dados. O slicing básico devolve uma view. Se fizeres slice dos primeiros dez elementos de um array e os modificares, o array original muda. O boolean masking comporta-se de maneira completamente diferente. Como o boolean masking é uma forma de advanced indexing, devolve sempre uma cópia dos dados, nunca uma view. A razão é a arquitetura de memória. Quando fazes slicing, o NumPy simplesmente altera os pointers para um bloco de memória contínuo e já existente. Mas quando aplicas uma boolean mask, os elementos que selecionas são completamente arbitrários. Já não estão organizados lado a lado na memória. O NumPy tem de os reunir e alocar novo espaço para guardar o resultado. Isto significa que, se modificares o teu array recém-filtrado de temperaturas negativas, o teu dataset original permanece completamente intacto. Também podes fazer chain destas condições. Se precisares de temperaturas abaixo de zero, mas estritamente acima de menos dez graus, combinas as duas condições lógicas. O NumPy avalia a lógica combinada elemento a elemento e constrói uma única mask precisa. Quando aplicas uma boolean mask, estás a trocar a eficiência de memória de uma view pela precisão absoluta de filtragem, o que te dá uma cópia impecável e independente exatamente dos dados que pediste. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. NumPy, episódio 7 de 7. Com as frameworks de GPU modernas a tratar do processamento pesado em machine learning, podes pensar que o NumPy se está a tornar obsoleto. Podes até presumir que converter um tensor de CPU do PyTorch num array NumPy requer uma memory copy lenta, prejudicando o desempenho do teu pipeline. Nenhuma das duas é verdadeira. A realidade é que o NumPy atua como o Tradutor Universal: Interoperabilidade, mantendo todo o ecossistema de dados de Python unido. Pensa num pipeline standard de machine learning. Usas o Pandas para carregar e limpar um dataset tabular massivo. Extrais esses valores para o NumPy para aplicar um filtro matemático especializado. Finalmente, passas esses dados filtrados para o PyTorch para treinar uma rede neuronal. Se cada uma destas libraries isolasse os seus dados, passar de etapa em etapa significaria duplicar todo o dataset em memória repetidamente. Esgotarias a tua RAM e desperdiçarias tempo de processamento apenas a mover bytes de um lado para o outro. Em vez disso, graças à magia da interoperabilidade, os dados nunca chegam a mover-se. O Pandas, o NumPy e o PyTorch simplesmente partilham exatamente o mesmo pointer de memória subjacente. Quando o PyTorch lê os dados, está a olhar para os exatos mesmos endereços de memória física que o Pandas alocou originalmente. Esta partilha zero copy é tornada possível por protocolos de memória standard. O fundamental é a array interface. Se um objeto Python expõe esta interface, ele essencialmente entrega um pequeno dicionário de metadados. Estes metadados dizem ao NumPy exatamente onde os raw data começam em memória, que shape assumem e que data type contêm. Quando chamas uma função do NumPy num objeto compatível, o NumPy lê essas instruções e envolve o bloco de memória existente com a sua própria estrutura de array. Ele não cria um novo array; apenas cria uma nova view dos dados antigos. Aqui está a ideia chave. A array interface original foi desenhada principalmente para a memória standard do sistema. À medida que a data science se moveu para aceleradores de hardware, o ecossistema precisou de uma forma de partilhar dados a viver em GPUs ou chips customizados sem fazer o routing de volta pela CPU. Isto levou à adoção do DLPack. O DLPack é um standard moderno e aberto para partilhar arrays multidimensionais entre diferentes frameworks. Ele define uma estrutura estável que qualquer library pode produzir e consumir. Se tiveres um tensor numa framework como o PyTorch ou o JAX, podes exportá-lo usando o protocolo DLPack. O NumPy pode então ingeri-lo de forma transparente usando a sua função dedicada from dlpack. Embora o NumPy em si opere principalmente na CPU, o seu suporte para DLPack significa que pode atuar como o hub central de routing. Podes passar um objeto DLPack de uma framework de deep learning para o NumPy, ou do NumPy de volta para uma framework, tudo sem uma duplicação de dados dispendiosa. O NumPy há muito que deixou de ser apenas uma math library. É o standard de memória invisível que impede que o ecossistema de dados de Python se fragmente em ilhas isoladas e incompatíveis. Encorajo-te a explorar a documentação oficial, a experimentar estas conversões zero copy hands-on no teu próprio terminal, ou a visitar devstories dot eu para sugerir tópicos para as nossas futuras séries. É tudo por este episódio. Obrigado por ouvires, e continua a programar!