TURING, A. M. Computing Machinery and Intelligence. Mind, Oxford, v. 59, n. 236, p. 433-460, out. 1950. DOI: 10.1093/mind/LIX.236.433.

Tradução do inglês para português por Heliton Martins. Alguns termos originais são mantidos para maior clareza.

Read the original paper (in English):

• Official (publisher page) (paid);

• Original scan (no OCR, free);

• Digital transcription (natively digital, free).

Máquinas de calcular e inteligência

1. O jogo da imitação

Proponho-me a considerar a questão: "Podem as máquinas pensar?" Isso deveria começar com definições do significado dos termos "máquina" e "pensar". As definições poderiam ser formuladas de modo a refletir, tanto quanto possível, o uso normal das palavras, mas essa atitude é perigosa. Se o significado das palavras "máquina" e "pensar" for encontrado examinando-se como elas são comumente usadas, é difícil escapar à conclusão de que o significado e a resposta à pergunta "Podem as máquinas pensar?" devem ser buscados em uma pesquisa estatística, como uma pesquisa Gallup. Mas isso é um absurdo. Em vez de tentar tal definição, substituirei a pergunta por outra, que está intimamente relacionada a ela e é expressa em palavras relativamente inequívocas.

A nova forma do problema pode ser descrita em termos de um jogo que chamamos de "jogo da imitação". É jogado com três pessoas: um homem (A), uma mulher (B) e um interrogador (C), que pode ser de qualquer sexo. O interrogador fica em uma sala separada dos outros dois. O objetivo do jogo para o interrogador é determinar qual dos outros dois é o homem e qual é a mulher. Ele os conhece pelas etiquetas X e Y e, ao final do jogo, ele diz "X é A e Y é B" ou "X é B e Y é A". O interrogador pode fazer perguntas a A e B da seguinte forma:

C: Pode X, por favor, me dizer o comprimento de seu cabelo?

Agora, suponha que X seja realmente A; então A deve responder. O objetivo de A no jogo é tentar fazer com que C faça a identificação errada. Sua resposta poderia, portanto, ser:

"Meu cabelo é curto, e os fios mais longos têm cerca de nove polegadas de comprimento."

Para que o tom de voz não ajude o interrogador, as respostas devem ser escritas ou, melhor ainda, datilografadas. O arranjo ideal é ter um teleimpressor (teleprinter) comunicando-se entre as duas salas. Alternativamente, a pergunta e as respostas podem ser repetidas por um intermediário. O objetivo do jogo para a terceira jogadora (B) é ajudar o interrogador. A melhor estratégia para ela é, provavelmente, dar respostas verdadeiras. Ela pode adicionar às suas respostas coisas como: "Eu sou a mulher, não dê ouvidos a ele!", mas isso de nada adiantará, pois o homem pode fazer observações semelhantes.

Agora fazemos a pergunta: "O que acontecerá quando uma máquina assumir o papel de A neste jogo?" O interrogador decidirá errado com a mesma frequência quando o jogo é jogado assim, como ele faz quando o jogo é jogado entre um homem e uma mulher? Essas perguntas substituem a nossa original: "Podem as máquinas pensar?"

2. Crítica ao Novo Problema

Além de perguntar: "Qual é a resposta para esta nova forma da questão?", pode-se perguntar: "Esta nova questão é digna de ser investigada?". Investigaremos esta última questão sem mais delongas, interrompendo assim um regresso infinito.

O novo problema tem a vantagem de traçar uma linha bastante nítida entre as capacidades físicas e as intelectuais de um homem. Nenhum engenheiro ou químico afirma ser capaz de produzir um material que seja indistinguível da pele humana. É possível que em algum momento isso possa ser feito, mas mesmo supondo que essa invenção estivesse disponível, sentiríamos que não faria muito sentido tentar tornar uma "máquina pensante" mais humana, vestindo-a com tal carne artificial. A forma como apresentamos o problema reflete esse fato na condição que impede o interrogador de ver ou tocar os outros competidores, ou ouvir suas vozes. Algumas outras vantagens do critério proposto podem ser evidenciadas por exemplos de perguntas e respostas. Assim:

P: Por favor, escreva-me um soneto sobre o tema da Ponte Forth (Forth Bridge).

R: Deixe-me fora dessa. Eu nunca consegui escrever poesia.

P: Some 34957 a 70764.

R: (Pausa de cerca de 30 segundos e então dá como resposta) 105621.

P: Você joga xadrez?

R: Sim.

P: Eu tenho o Rei em K1 (Rei 1), e nenhuma outra peça. Você tem apenas o Rei em K6 (Rei 6) e a Torre em R1 (Torre 1). É a sua vez de jogar. O que você joga?

R: (Após uma pausa de 15 segundos) T-R8 mate (R-R8 mate).

O método de perguntas e respostas parece ser adequado para introduzir quase qualquer um dos campos do esforço humano que desejamos incluir. Não desejamos penalizar a máquina por sua incapacidade de brilhar em concursos de beleza, nem penalizar um homem por perder em uma corrida contra um avião. As condições do nosso jogo tornam essas deficiências irrelevantes. As "testemunhas" (witnesses) podem se gabar, se considerarem aconselhável, o quanto quiserem sobre seus encantos, força ou heroísmo, mas o interrogador não pode exigir demonstrações práticas.

O jogo talvez possa ser criticado com o argumento de que as chances estão excessivamente contra a máquina. Se o homem fosse tentar fingir ser a máquina, ele claramente teria um desempenho muito ruim. Ele seria denunciado imediatamente pela lentidão e imprecisão na aritmética. Não poderiam as máquinas realizar algo que deveria ser descrito como pensar, mas que é muito diferente do que um homem faz? Esta objeção é muito forte, mas pelo menos podemos dizer que se, no entanto, uma máquina puder ser construída para jogar o jogo da imitação satisfatoriamente, não precisaremos nos preocupar com esta objeção.

Poder-se-ia argumentar que, ao jogar o "jogo da imitação", a melhor estratégia para a máquina pode possivelmente ser algo diferente da imitação do comportamento de um homem. Isso pode ser, mas acho improvável que haja qualquer grande efeito desse tipo. De qualquer forma, não há intenção de investigar aqui a teoria do jogo, e será assumido que a melhor estratégia é tentar fornecer respostas que seriam naturalmente dadas por um homem.

3. As Máquinas Envolvidas no Jogo

A questão que colocamos no item 1 não será totalmente definida até que tenhamos especificado o que queremos dizer com a palavra "máquina". É natural que desejemos permitir que todo tipo de técnica de engenharia seja usado em nossas máquinas. Também desejamos permitir a possibilidade de que um engenheiro ou equipe de engenheiros possa construir uma máquina que funcione, mas cuja maneira de operação não possa ser satisfatoriamente descrita por seus construtores, porque eles aplicaram um método que é amplamente experimental. Finalmente, desejamos excluir das máquinas os homens nascidos da maneira usual. É difícil formular as definições de modo a satisfazer essas três condições. Poder-se-ia, por exemplo, insistir que a equipe de engenheiros fosse toda de um só sexo, mas isso não seria realmente satisfatório, pois é provavelmente possível criar um indivíduo completo a partir de uma única célula da pele (digamos) de um homem. Fazer isso seria um feito de técnica biológica merecedor dos maiores elogios, mas não estaríamos inclinados a considerá-lo como um caso de "construção de uma máquina pensante" (thinking machine). Isso nos leva a abandonar a exigência de que todo tipo de técnica seja permitido. Estamos ainda mais dispostos a fazê-lo em vista do fato de que o interesse atual por "máquinas pensantes" foi despertado por um tipo particular de máquina, geralmente chamada de "computador eletrônico" (electronic computer) ou "computador digital" (digital computer). Seguindo essa sugestão, permitimos apenas que computadores digitais participem do nosso jogo.

Essa restrição parece, à primeira vista, muito drástica. Tentarei mostrar que, na realidade, ela não o é. Fazer isso exige uma breve descrição da natureza e das propriedades desses computadores.

Pode-se dizer também que essa identificação de máquinas com computadores digitais, assim como nosso critério para "pensar", só será insatisfatória se (contrariando minha crença) se revelar que os computadores digitais são incapazes de ter um bom desempenho no jogo.

Já existem vários computadores digitais em funcionamento, e pode-se perguntar: "Por que não tentar o experimento imediatamente? Seria fácil satisfazer as condições do jogo. Vários interrogadores poderiam ser usados, e estatísticas compiladas para mostrar com que frequência a identificação correta foi dada." A resposta curta é que não estamos perguntando se todos os computadores digitais se sairiam bem no jogo, nem se os computadores atualmente disponíveis se sairiam bem, mas se existem computadores imagináveis que se sairiam bem. Mas esta é apenas a resposta curta. Veremos essa questão sob uma luz diferente mais adiante.

4. Computadores Digitais

A ideia por trás dos computadores digitais pode ser explicada dizendo que essas máquinas se destinam a realizar quaisquer operações que poderiam ser feitas por um computador humano. Supõe-se que o computador humano siga regras fixas; ele não tem autoridade para desviar-se delas em nenhum detalhe. Podemos supor que essas regras são fornecidas em um livro, que é alterado sempre que ele é colocado em um novo trabalho. Ele também tem um suprimento ilimitado de papel no qual faz seus cálculos. Ele também pode fazer suas multiplicações e adições em uma "máquina de calcular" (desk machine), mas isso não é importante.

Se usarmos a explicação acima como definição, estaremos em perigo de circularidade de argumento. Evitamos isso dando um esboço dos meios pelos quais o efeito desejado é alcançado. Um computador digital geralmente pode ser considerado como constituído por três partes:

1. Memória (Store)

2. Unidade de Execução (Executive unit)

3. Controle (Control)

A memória é um armazém de informações e corresponde ao papel do computador humano, seja este o papel no qual ele faz seus cálculos ou aquele no qual seu livro de regras está impresso. Na medida em que o computador humano faz cálculos de cabeça (in his head), uma parte da memória corresponderá à sua memória (mental).

A unidade de execução é a parte que realiza as várias operações individuais envolvidas em um cálculo. Quais são essas operações individuais, varia de máquina para máquina. Geralmente, operações bastante longas podem ser feitas, como "Multiplicar 3540675445 por 7076345687", mas em algumas máquinas apenas operações muito simples, como "Escreva 0", são possíveis.

Mencionamos que o "livro de regras" fornecido ao computador é substituído na máquina por uma parte da memória. É então chamado de "tabela de instruções". É dever do controle (control) garantir que essas instruções sejam obedecidas corretamente e na ordem certa. O controle é construído de forma que isso aconteça necessariamente.

A informação na memória é geralmente dividida em pacotes de tamanho moderadamente pequeno. Em uma máquina, por exemplo, um pacote pode consistir em dez dígitos decimais. Números são atribuídos às partes da memória onde os vários pacotes de informação são armazenados, de alguma maneira sistemática. Uma instrução típica poderia dizer:

"Some o número armazenado na posição 6809 ao da posição 4302 e coloque o resultado de volta nesta última posição de armazenamento."

Desnecessário dizer que isso não ocorreria na máquina expresso em inglês. Seria mais provável que estivesse codificado em uma forma como 6809430217. Aqui, 17 diz qual das várias operações possíveis deve ser realizada sobre os dois números. Neste caso, a operação é a descrita acima, a saber: "Some o número...". Nota-se que a instrução ocupa 10 dígitos e, assim, forma um pacote de informação, muito convenientemente. O controle (control) normalmente pegará as instruções a serem obedecidas na ordem das posições em que estão armazenadas, mas ocasionalmente uma instrução como:

"Agora obedeça à instrução armazenada na posição 5606 e continue a partir daí"

pode ser encontrada, ou ainda:

"Se a posição 4505 contém 0, obedeça em seguida à instrução armazenada em 6707; caso contrário, continue em frente."

Instruções desses últimos tipos são muito importantes porque tornam possível que uma sequência de operações seja repetida (replaced) várias vezes até que alguma condição seja satisfeita, mas, ao fazê-lo, obedecendo não a novas instruções a cada repetição, mas às mesmas repetidamente. Tomando uma analogia doméstica, suponha que a Mãe queira que Tommy passe no sapateiro toda manhã a caminho da escola para ver se os sapatos dela estão prontos. Ela pode pedir-lhe de novo toda manhã. Alternativamente, ela pode afixar um aviso de uma vez por todas no corredor, que ele verá quando sair para a escola e que lhe diz para passar a buscar os sapatos, e também para destruir o aviso quando voltar, se ele tiver os sapatos consigo.

O leitor deve aceitar como fato que os computadores digitais podem ser construídos, e de fato foram construídos, de acordo com os princípios que descrevemos, e que eles podem, na verdade, imitar as ações de um computador humano muito de perto.

O livro de regras que descrevemos nosso computador humano usando é, naturalmente, uma ficção conveniente. Computadores humanos reais realmente se lembram do que têm de fazer. Se alguém quer fazer uma máquina imitar o comportamento do computador humano em alguma operação complexa, tem de perguntar-lhe como é feito e, em seguida, traduzir a resposta para a forma de uma tabela de instruções. Construir tabelas de instruções é geralmente descrito como "programar" (programming). "Programar uma máquina para realizar a operação A" significa colocar a tabela de instruções apropriada na máquina para que ela faça A.

Uma variante interessante da ideia de um computador digital é um "computador digital com um elemento aleatório" (digital computer with a random element). Estes têm instruções que envolvem o lançamento de um dado ou algum processo eletrônico equivalente; uma dessas instruções poderia, por exemplo, ser: "Lance o dado e coloque o número resultante na memória 1000". Às vezes, tal máquina é descrita como tendo livre-arbítrio (free will) (embora eu mesmo não usasse essa frase). Normalmente não é possível determinar, observando uma máquina, se ela tem um elemento aleatório, pois um efeito semelhante pode ser produzido por dispositivos como fazer as escolhas dependerem dos dígitos da dízima de $\pi$.

A maioria dos computadores digitais reais tem apenas uma memória (store) finita. Não há dificuldade teórica na ideia de um computador com uma memória ilimitada. Claro, apenas uma parte finita pode ter sido usada a qualquer momento. Da mesma forma, apenas uma quantidade finita pode ter sido construída, mas podemos imaginar mais e more sendo adicionada conforme necessário. Tais computadores têm especial interesse teórico e serão chamados de computadores de capacidade infinita.

A ideia de um computador digital é antiga. Charles Babbage, Professor Lucasiano de Matemática em Cambridge de 1828 a 1839, planejou tal máquina, chamada de Máquina Analítica (Analytical Engine), mas ela nunca foi concluída. Embora Babbage tivesse todas as ideias essenciais, sua máquina não era, naquela época, uma perspectiva tão atraente. A velocidade que estaria disponível seria definitivamente mais rápida que a de um computador humano, mas algo como 100 vezes mais lenta que a máquina de Manchester, ela própria uma das mais lentas das máquinas modernas. O armazenamento (storage) deveria ser puramente mecânico, usando rodas e cartões.

O fato de a Máquina Analítica de Babbage ser inteiramente mecânica nos ajudará a nos livrarmos de uma superstição. Importância é frequentemente atribuída ao fato de que os computadores digitais modernos são elétricos, e que o sistema nervoso também é elétrico. Visto que a máquina de Babbage não era elétrica, e dado que todos os computadores digitais são, em certo sentido, equivalentes, vemos que esse uso da eletricidade não pode ser de importância teórica. É claro que a eletricidade geralmente entra em cena quando se trata de sinalização rápida, de modo que não é surpreendente que a encontremos em ambas as conexões. No sistema nervoso, os fenômenos químicos são pelo menos tão importantes quanto os elétricos. Em certos computadores, o sistema de armazenamento (storage) é principalmente acústico. A característica de usar eletricidade é, portanto, vista como sendo apenas uma semelhança muito superficial. Se quisermos encontrar tais semelhanças, deveríamos procurar, em vez disso, por analogias matemáticas de função.

5. Universalidade dos Computadores Digitais

Os computadores digitais considerados na última seção podem ser classificados entre as "máquinas de estados discretos" (discrete-state machines). Estas são as máquinas que se movem por saltos (jumps) ou cliques (clicks) repentinos de um estado bastante definido para outro. Esses estados são suficientemente diferentes para que a possibilidade de confusão entre eles seja ignorada. A rigor, não existem tais máquinas. Tudo, na realidade, move-se continuamente. Mas há muitos tipos de máquina que podem vantajosamente (profitably) ser pensadas como sendo máquinas de estados discretos. Por exemplo, ao considerar os interruptores de um sistema de iluminação, é uma ficção conveniente que cada interruptor deva estar definitivamente ligado (on) ou definitivamente desligado (off). Deve haver posições intermediárias, mas, para a maioria dos propósitos, podemos esquecê-las.

Como exemplo de uma máquina de estados discretos, poderíamos considerar uma roda que gira com um clique 120° uma vez por segundo, mas pode ser parada por uma alavanca que pode ser operada de fora; além disso, uma lâmpada deve acender em uma das posições da roda. Esta máquina poderia ser descrita abstratamente da seguinte forma. O estado interno da máquina (que é descrito pela posição da roda) pode ser $q_1$, $q_2$ ou $q_3$. Existe um sinal de entrada $i_0$ ou $i_1$ (posição da alavanca). O estado interno a qualquer momento é determinado pelo último estado e pelo sinal de entrada, de acordo com a tabela:

(TABELA OMITIDA)

Os sinais de saída, a única indicação externamente visível do estado interno (a luz), são descritos pela tabela:

Este exemplo é típico de máquinas de estados discretos. Elas podem ser descritas por tais tabelas, desde que tenham apenas um número finito de estados possíveis.

Parecerá que, dado o estado inicial da máquina e os sinais de entrada, é sempre possível prever todos os estados futuros. Isso é reminiscente da visão de Laplace de que, a partir do estado completo do universo em um momento, descrito pelas posições e velocidades de todas as partículas, deveria ser possível prever todos os estados futuros. A predição que estamos considerando está, no entanto, bem mais próxima da praticabilidade (practicability) do que a considerada por Laplace. O sistema do "universo como um todo" (universe as a whole) é tal que erros bastante pequenos nas condições iniciais podem ter um efeito avassalador em um momento posterior. O deslocamento de um único elétron por um bilionésimo de centímetro em um momento pode fazer a diferença entre um homem ser morto por uma avalanche um ano depois, ou escapar. É uma propriedade essencial dos sistemas mecânicos que chamamos de "máquinas de estados discretos" que esse fenômeno não ocorra. Mesmo quando consideramos as máquinas físicas reais em vez das máquinas idealizadas, um conhecimento razoavelmente preciso do estado em um momento fornece um conhecimento razoavelmente preciso vários passos adiante.

Como mencionamos, os computadores digitais se enquadram na classe das máquinas de estados discretos. Mas o número de estados de que tal máquina é capaz é geralmente enormemente grande. Por exemplo, o número para a máquina que agora opera em Manchester é de cerca de $2^{165,000}$, ou seja, cerca de $10^{50,000}$. Compare isso com nosso exemplo da roda com clique (clicking wheel) descrito acima, que tinha três estados. Não é difícil ver por que o número de estados deve ser tão imenso. O computador inclui uma memória (store) correspondente ao papel usado por um computador humano. Deve ser possível escrever na memória qualquer uma das combinações de símbolos que poderiam ter sido escritas no papel. Por simplicidade, suponha que apenas dígitos de 0 a 9 sejam usados como símbolos. Variações na caligrafia são ignoradas. Suponha que o computador tenha permissão para 100 folhas de papel, cada uma contendo 50 linhas, cada uma com espaço para 30 dígitos. Então, o número de estados é $10^{100 \times 50 \times 30}$, ou seja, $10^{150,000}$. Isso é aproximadamente o número de estados de três máquinas de Manchester juntas.

O logaritmo na base dois do número de estados é usualmente chamado de "capacidade de armazenamento" (storage capacity) da máquina. Assim, a máquina de Manchester tem uma capacidade de armazenamento de cerca de 165,000 e a máquina da roda do nosso exemplo, cerca de 1,6. Se duas máquinas são postas juntas, suas capacidades devem ser somadas para obter a capacidade da máquina resultante. Isso leva à possibilidade de declarações como: "A máquina de Manchester contém 64 trilhas magnéticas, cada uma com capacidade de 2560, oito tubos eletrônicos com capacidade de 1280. Armazenamento diverso (Miscellaneous storage) soma cerca de 300, perfazendo um total de 174,380."

Dada a tabela correspondente a uma máquina de estados discretos, é possível prever o que ela fará. Não há razão para que esse cálculo não deva ser realizado por meio de um computador digital. Desde que pudesse ser realizado rápido o suficiente, o computador digital poderia imitar o comportamento de qualquer máquina de estados discretos. O jogo da imitação poderia então ser jogado com a máquina em questão (como B) e o computador digital imitador (como A), e o interrogador não conseguiria distingui-los. É claro que o computador digital deve ter uma capacidade de armazenamento adequada, além de funcionar rápido o suficiente. Além disso, ele deve ser programado de novo para cada nova máquina que se deseja imitar.

Essa propriedade especial dos computadores digitais, de que eles podem imitar qualquer máquina de estados discretos, é descrita dizendo-se que eles são máquinas universais (universal machines). A existência de máquinas com essa propriedade tem a importante consequência de que, deixando de lado considerações de velocidade, é desnecessário projetar várias máquinas novas para fazer vários processos de computação. Todos eles podem ser feitos com um único computador digital, adequadamente programado para cada caso. Ver-se-á que, como consequência disso, todos os computadores digitais são, em certo sentido, equivalentes.

Devemos agora considerar novamente o ponto levantado ao final do §3. Foi sugerido, tentativamente, que a questão "Podem as máquinas pensar?" (Can machines think?) fosse substituída por "Existem computadores digitais imagináveis que se sairiam bem no jogo da imitação?". Se quisermos, podemos tornar isso superficialmente mais geral e perguntar: "Existem máquinas de estados discretos que se sairiam bem?". Mas, em vista da propriedade da universalidade, vemos que qualquer uma dessas questões é equivalente a esta: "Vamos fixar nossa atenção em um computador digital específico C. É verdade que, modificando este computador para ter um armazenamento adequado, aumentando adequadamente sua velocidade de ação e fornecendo-lhe um programa apropriado, C pode ser levado a desempenhar satisfatoriamente o papel de A no jogo da imitação, sendo o papel de B desempenhado por um homem?"

6. Visões Contrárias sobre a Questão Principal

Podemos agora considerar que o terreno foi preparado e estamos prontos para prosseguir com o debate sobre a nossa questão, "Podem as máquinas pensar?" (Can machines think?), e a variante dela citada ao final da última seção. Não podemos abandonar totalmente a forma original do problema, pois as opiniões divergirão quanto à adequação da substituição e devemos, pelo menos, ouvir o que tem a ser dito a esse respeito (in this connexion).

Simplificará as coisas para o leitor se eu explicar primeiro minhas próprias crenças sobre o assunto. Considere primeiro a forma mais precisa da questão. Eu acredito que em cerca de cinquenta anos será possível programar computadores, com uma capacidade de armazenamento de cerca de $10^9$, para fazê-los jogar o jogo da imitação tão bem que um interrogador médio não terá mais que 70 por cento de chance de fazer a identificação correta após cinco minutos de questionamento. A questão original, "Podem as máquinas pensar?", eu acredito ser desprovida de sentido (too meaningless) demais para merecer discussão.

No entanto, acredito que no final do século o uso das palavras e a opinião educada geral terão se alterado tanto que será possível falar de máquinas pensando sem esperar ser contradito. Acredito ainda que nenhum propósito útil é servido ao esconder essas crenças. A visão popular de que os cientistas procedem inexoravelmente de fato bem estabelecido para fato bem estabelecido, nunca sendo influenciados por qualquer conjectura aprimorada (improved conjecture), é bastante equivocada. Contanto que fique claro quais são fatos comprovados e quais são conjecturas, nenhum dano pode resultar. Conjecturas são de grande importância, pois sugerem linhas úteis de pesquisa.

Passo agora a considerar as opiniões opostas à minha.

6.1. A Objeção Teológica

Pensar é uma função da alma imortal do homem. Deus deu uma alma imortal a cada homem e mulher, mas não a qualquer outro animal ou às máquinas. Portanto, nenhum animal ou máquina pode pensar.

Sou incapaz de aceitar qualquer parte disso, mas tentarei responder em termos teológicos. Eu acharia o argumento mais convincente se os animais fossem classificados com os homens, pois há uma diferença maior, em minha opinião, entre o animado típico e o inanimado do que há entre o homem e os outros animais. O caráter arbitrário da visão ortodoxa torna-se mais claro se considerarmos como ela poderia parecer a um membro de alguma outra comunidade religiosa. Como os cristãos consideram a visão muçulmana de que as mulheres não têm alma? Mas deixemos esse ponto de lado e voltemos ao argumento principal. Parece-me que o argumento citado acima implica uma séria restrição à onipotência do Todo-Poderoso. Admite-se que há certas coisas que Ele não pode fazer, como fazer um ser igual a dois, mas não deveríamos acreditar que Ele tem a liberdade de conferir uma alma a um elefante, se Ele assim o julgar? Poderíamos esperar que Ele apenas exercesse esse poder em conjunção com uma mutação que fornecesse ao elefante um cérebro apropriadamente melhorado para atender às necessidades desse tipo. Um argumento de forma exatamente similar pode ser feito para o caso das máquinas. Pode parecer diferente porque é mais difícil de "engolir" (swallow). Mas isso, na verdade, significa apenas que pensamos que seria menos provável que Ele considerasse as circunstâncias adequadas para conferir uma alma. As circunstâncias em questão são discutidas no restante deste artigo. Ao tentar construir tais máquinas, não estaríamos usurpando irreverentemente Seu poder de criar almas, assim como não o fazemos na procriação de filhos: em vez disso, somos, em ambos os casos, instrumentos de Sua vontade, provendo mansões (mansions) para as almas que Ele cria.

No entanto, isso é mera especulação. Não estou muito impressionado com argumentos teológicos, independentemente do que eles sejam usados para apoiar. Tais argumentos muitas vezes se mostraram insatisfatórios no passado. Na época de Galileu, argumentava-se que os textos:

"E o sol se deteve... e não se apressou a pôr-se, quase um dia inteiro" (Josué x. 13)

e

"Ele lançou os fundamentos da terra, para que ela não se movesse em tempo algum" (Salmos cv. 5)

eram uma refutação adequada da teoria copernicana. Com o nosso conhecimento atual, tal argumento parece fútil. Quando esse conhecimento não estava disponível, ele causava uma impressão bem diferente.

6.2. A Objeção "Cabeças na Areia"

"As consequências de máquinas pensantes seriam terríveis demais. Esperemos e acreditemos que elas não possam fazê-lo."

Este argumento raramente é expresso tão abertamente quanto na forma acima. Mas ele afeta a maioria de nós que pensa sobre o assunto. Gostamos de acreditar que o Homem é, de alguma forma sutil, superior ao resto da criação. É melhor se puder ser demonstrado que ele é necessariamente superior, pois assim não há perigo de ele perder sua posição de comando. A popularidade do argumento teológico está claramente ligada a esse sentimento. É provável que seja bastante forte em pessoas intelectuais, já que elas valorizam o poder de pensar mais do que as outras, e estão mais inclinadas a basear sua crença na superioridade do Homem nesse poder.

Não creio que este argumento seja suficientemente substancial para exigir refutação. Consolo seria mais apropriado: talvez este deva ser buscado na transmigração das almas.

6.3. A Objeção Matemática

Existem vários resultados da lógica matemática que podem ser usados para mostrar que há limitações aos poderes das máquinas de estados discretos. O mais conhecido desses resultados é o teorema de Gödel (1931), que mostra que em qualquer sistema lógico suficientemente poderoso, podem ser formuladas declarações que não podem ser nem provadas nem refutadas dentro do sistema, a menos que, possivelmente, o próprio sistema seja inconsistente. Existem outros resultados, em alguns aspectos semelhantes, devidos a Church (1936), Kleene (1935), Rosser e Turing (1937).

O último resultado é o mais conveniente a se considerar, pois se refere diretamente a máquinas, enquanto os outros só podem ser usados em um argumento comparativamente indireto: por exemplo, se o teorema de Gödel for usado, precisamos adicionalmente ter algum meio de descrever sistemas lógicos em termos de máquinas, e máquinas em termos de sistemas lógicos. O resultado em questão refere-se a um tipo de máquina que é essencialmente um computador digital com capacidade infinita. Ele afirma que há certas coisas que tal máquina não pode fazer. Se ela for preparada (rigged up) para dar respostas a perguntas como no jogo da imitação, haverá algumas perguntas para as quais ela ou dará uma resposta errada, ou falhará totalmente em dar uma resposta, não importa quanto tempo seja concedido para uma réplica. Pode haver, é claro, muitas dessas perguntas, e perguntas que não podem ser respondidas por uma máquina podem ser satisfatoriamente respondidas por outra. Estamos, é claro, supondo no momento que as perguntas são do tipo para as quais uma resposta "Sim" ou "Não" é apropriada, em vez de perguntas como "O que você acha de Picasso?". As perguntas em que sabemos que as máquinas devem falhar são deste tipo:

"Considere a máquina especificada a seguir... . Esta máquina algum dia responderá 'Sim' a alguma pergunta?"

As reticências devem ser substituídas pela descrição de alguma máquina em um formato padrão, que poderia ser algo como o usado no §5. Quando a máquina descrita tem uma certa relação comparativamente simples com a máquina que está sob interrogação, pode-se mostrar que a resposta está errada ou não é fornecida (not forthcoming). Este é o resultado matemático: argumenta-se que ele prova uma incapacidade (disability) das máquinas à qual o intelecto humano não está sujeito.

A resposta curta a este argumento é que, embora esteja estabelecido que existem limitações aos poderes de qualquer máquina específica, foi apenas afirmado, sem qualquer tipo de prova, que tais limitações não se aplicam ao intelecto humano. Mas eu não acho que essa visão possa ser descartada tão levianamente. Sempre que uma dessas máquinas é questionada com a pergunta crítica apropriada, e dá uma resposta definitiva, sabemos que essa resposta deve estar errada, e isso nos dá um certo sentimento de superioridade. Esse sentimento é ilusório? É, sem dúvida, bastante genuío, mas não acho que se deva dar muita importância a ele. Nós mesmos damos respostas erradas a perguntas com muita frequência para nos justificarmos em ficar muito satisfeitos (pleased) com tal evidência de falibilidade por parte das máquinas. Além disso, nossa superioridade só pode ser sentida em tal ocasião em relação àquela máquina sobre a qual conquistamos nosso pequeno triunfo (petty triumph). Não haveria questão de triunfar simultaneamente sobre todas as máquinas. Em resumo, então, pode haver homens mais espertos do que qualquer máquina específica, mas, novamente, pode haver outras máquinas mais espertas ainda, e assim por diante.

Aqueles que se apegam ao argumento matemático estariam, eu acho, em sua maioria dispostos a aceitar o jogo da imitação como base para discussão. Aqueles que acreditam nas duas objeções anteriores provavelmente não estariam interessados em critério algum.

6.4. O Argumento da Consciência

Este argumento é muito bem expresso na Oração Lister (Lister Oration) do Professor Jefferson em 1949, da qual cito:

"Não até que uma máquina possa escrever um soneto ou compor um concerto por causa de pensamentos e emoções sentidos, e não pela queda casual de símbolos, poderíamos concordar que máquina é igual a cérebro — ou seja, não apenas escrevê-lo, mas saber que o escreveu. Nenhum mecanismo poderia sentir — e não meramente sinalizar artificialmente, um artifício fácil (an easy contrivance) — prazer com seus sucessos, tristeza quando suas válvulas queimam, ser aquecido por lisonjas, ser miserabilizado por seus erros, ser encantado pelo sexo, ficar com raiva ou deprimido quando não consegue o que quer."

Este argumento parece ser uma negação da validade do nosso teste. De acordo com a forma mais extrema desta visão, a única maneira pela qual se poderia ter certeza de que uma máquina pensa é sendo a máquina e sentindo-se pensando. Poder-se-ia então descrever esses sentimentos ao mundo, mas é claro que ninguém estaria justificado em dar qualquer atenção. Da mesma forma, de acordo com essa visão, a única maneira de saber que um homem pensa é sendo aquele homem em particular. É, de fato, o ponto de vista solipsista. Pode ser a visão mais lógica a se sustentar, mas torna a comunicação de ideias difícil. A é propenso a acreditar "A pensa, mas B não", enquanto B acredita "B pensa, mas A não". Em vez de discutir continuamente sobre este ponto, é usual ter a convenção educada (polite convention) de que todos pensam.

Tenho certeza de que o Professor Jefferson não deseja adotar o ponto de vista extremo e solipsista. Provavelmente, ele estaria totalmente disposto a aceitar o jogo da imitação como um teste. O jogo (com o jogador B omitido) é frequentemente usado na prática sob o nome de viva voce (exame oral) para descobrir se alguém realmente entende algo ou se "aprendeu como um papagaio" (learnt it parrot fashion). Vamos escutar um trecho de um desses viva voce:

Interrogador: No primeiro verso do seu soneto, que diz "Devo comparar-te a um dia de verão" (Shall I compare thee to a summer's day), "um dia de primavera" (a spring day) não serviria tão bem ou melhor?

Testemunha: Não daria a métrica (It wouldn't scan).

Interrogador: Que tal "um dia de inverno" (a winter's day)? Isso daria a métrica corretamente.

Testemunha: Sim, mas ninguém quer ser comparado a um dia de inverno.

Interrogador: Você diria que o Sr. Pickwick o lembra do Natal?

Testemunha: De certa forma.

Interrogador: No entanto, o Natal é um dia de inverno, e não acho que o Sr. Pickwick se importaria com a comparação.

Testemunha: Acho que você não está falando sério. Por "um dia de inverno", quer-se dizer um dia de inverno típico, em vez de um especial como o Natal.

E assim por diante. O que o Professor Jefferson diria se a máquina de escrever sonetos fosse capaz de responder assim no viva voce? Não sei se ele consideraria a máquina como "meramente sinalizando artificialmente" (merely artificially signalling) essas respostas, mas se as respostas fossem tão satisfatórias e sustentadas como na passagem acima, não acho que ele a descreveria como "um artifício fácil" (an easy contrivance). Essa frase, eu acho, destina-se a cobrir dispositivos como a inclusão na máquina de uma gravação de alguém lendo um soneto, com comutação apropriada para ligá-la de tempos em tempos.

Em resumo, então, acho que a maioria daqueles que apoiam o argumento da consciência poderia ser persuadida a abandoná-lo, em vez de ser forçada à posição solipsista. Eles então provavelmente estarão dispostos a aceitar nosso teste.

Não desejo dar a impressão de que acho que não há mistério sobre a consciência. Há, por exemplo, algo de paradoxal conectado a qualquer tentativa de localizá-la. Mas não acho que esses mistérios precisem necessariamente ser resolvidos antes que possamos responder à pergunta com a qual estamos preocupados neste artigo.

6.5. Argumentos de Várias Debilidades

Estes argumentos assumem a forma: "Admito que você pode fazer máquinas realizarem todas as coisas que mencionou, mas você nunca será capaz de fazer uma que faça X." Inúmeras características X são sugeridas a este respeito. Ofereço uma seleção:

Ser gentil, engenhosa (resourceful), bonita, amigável, ter iniciativa, ter senso de humor, distinguir o certo do errado, cometer erros, apaixonar-se, apreciar (enjoy) morangos com creme, fazer alguém se apaixonar por ela, aprender com a experiência, usar palavras apropriadamente, ser o sujeito de seu próprio pensamento, ter tanta diversidade de comportamento quanto um homem, fazer algo realmente novo.

Normalmente, nenhuma sustentação é oferecida para essas afirmações. Acredito que elas se baseiam principalmente no princípio da indução científica. Um homem viu milhares de máquinas em sua vida. A partir do que ele vê delas, ele extrai várias conclusões gerais. Elas são feias, cada uma é projetada para um propósito muito limitado, quando exigidas para um propósito minuciosamente diferente são inúteis, a variedade de comportamento de qualquer uma delas é muito pequena, etc., etc. Naturalmente, ele conclui que essas são propriedades necessárias das máquinas em geral.

Muitas dessas limitações estão associadas à capacidade de armazenamento muito pequena da maioria das máquinas. (Estou assumindo que a ideia de capacidade de armazenamento é estendida de alguma forma para cobrir outras máquinas além das máquinas de estados discretos. A definição exata não importa, pois nenhuma precisão matemática é reivindicada na presente discussão.) Alguns anos atrás, quando muito pouco se tinha ouvido falar sobre computadores digitais, era possível suscitar muita incredulidade a respeito deles, se alguém mencionasse suas propriedades sem descrever sua construção. Isso se devia, presumivelmente, a uma aplicação semelhante do princípio da indução científica.

Essas aplicações do princípio são, naturalmente, em grande parte inconscientes. Quando uma criança queimada teme o fogo e demonstra temê-lo, evitando-o, eu diria que ela estava aplicando a indução científica. (Eu poderia, é claro, descrever seu comportamento de muitas outras maneiras.) As obras (works) e os costumes da humanidade não parecem ser um material muito adequado ao qual aplicar a indução científica. Uma parte muito grande do espaço-tempo deve ser investigada, se quisermos obter resultados confiáveis. Caso contrário, podemos (como a maioria das crianças inglesas faz) decidir que todo mundo fala inglês e que é bobagem aprender francês.

Existem, no entanto, observações especiais a serem feitas sobre muitas das debilidades (disabilities) que foram mencionadas. A incapacidade de apreciar morangos com creme pode ter parecido frívola ao leitor. Possivelmente, uma máquina poderia ser feita para apreciar esta iguaria, mas qualquer tentativa de fazê-la seria completamente idiota (idiotic). O que é importante sobre essa debilidade é que ela contribui para algumas das outras debilidades, por exemplo, para a dificuldade de ocorrer o mesmo tipo de amizade entre homem e máquina, como ocorre entre homem branco e homem branco, ou entre homem negro e homem negro.

A alegação de que "máquinas não podem cometer erros" (machines cannot make mistakes) parece curiosa. Fica-se tentado a replicar: "Elas são piores por causa disso?" Mas adotemos uma atitude mais simpática e tentemos ver o que realmente se quer dizer. Acho que essa crítica pode ser explicada em termos do jogo da imitação. Alega-se que o interrogador poderia distinguir a máquina do homem simplesmente apresentando-lhes vários problemas de aritmética. A máquina seria desmascarada por causa de sua precisão implacável (deadly accuracy). A réplica a isso é simples. A máquina (programada para jogar o jogo) não tentaria dar as respostas corretas aos problemas de aritmética. Ela introduziria erros deliberadamente, de uma maneira calculada para confundir o interrogador. Uma falha mecânica (mechanical fault) provavelmente se manifestaria através de uma decisão inadequada sobre que tipo de erro cometer na aritmética. Mesmo essa interpretação da crítica não é suficientemente simpática. Mas não podemos nos dar ao luxo (we cannot afford the space) de nos aprofundar muito mais nisso.

Parece-me que esta crítica depende de uma confusão entre dois tipos de erro. Podemos chamá-los de "erros de funcionamento" (errors of functioning) e "erros de conclusão" (errors of conclusion). Erros de funcionamento devem-se a alguma falha mecânica ou elétrica que faz com que a máquina se comporte de maneira diferente da qual foi projetada. Em discussões filosóficas, gosta-se de ignorar a possibilidade de tais erros; está-se, portanto, discutindo "máquinas abstratas" (abstract machines). Essas máquinas abstratas são ficções matemáticas, e não objetos físicos. Por definição, elas são incapazes de erros de funcionamento. Nesse sentido, podemos realmente dizer que "máquinas nunca podem cometer erros". Erros de conclusão só podem surgir quando algum significado é atribuído aos sinais de saída (output signals) da máquina. A máquina pode, por exemplo, datilografar equações matemáticas ou sentenças em inglês. Quando uma proposição falsa é datilografada, dizemos que a máquina cometeu um erro de conclusão. Claramente, não há razão alguma para dizer que uma máquina não pode cometer esse tipo de erro. Ela poderia não fazer nada além de datilografar repetidamente "$0 = 1$". Para tomar um exemplo menos perverso, ela poderia ter algum método para extrair conclusões por indução científica. Devemos esperar que tal método leve, ocasionalmente, a resultados errôneos.

A alegação de que uma máquina não pode ser o sujeito (subject) de seu próprio pensamento só pode, é claro, ser respondida se for possível mostrar que a máquina tem algum pensamento com algum assunto (subject matter). No entanto, o assunto (subject matter) das operações de uma máquina parece significar algo, pelo menos para as pessoas que lidam com ela. Se, por exemplo, a máquina estivesse tentando encontrar uma solução para a equação $x^2 - 40x - 11 = 0$, seria tentador descrever essa equação como parte do assunto (subject matter) da máquina naquele momento. Nesse tipo de sentido, uma máquina indubitavelmente pode ser seu próprio assunto (subject matter). Ela pode ser usada para ajudar a elaborar seus próprios programas, ou para prever o efeito de alterações em sua própria estrutura. Ao observar os resultados de seu próprio comportamento, ela pode modificar seus próprios programas de modo a atingir algum propósito mais eficazmente. Essas são possibilidades de um futuro próximo, e não sonhos utópicos.

A crítica de que uma máquina não pode ter muita diversidade de comportamento é apenas uma forma de dizer que ela não pode ter muita capacidade de armazenamento. Até bem recentemente, uma capacidade de armazenamento de até mesmo mil dígitos era muito rara.

As críticas que estamos considerando aqui são, muitas vezes, formas disfarçadas do argumento da consciência. Geralmente, se alguém sustenta que uma máquina pode fazer uma dessas coisas e descreve o tipo de método que a máquina poderia usar, não causará uma grande impressão. Pensa-se que o método (seja ele qual for, pois deve ser mecânico) é, na realidade, bastante vil (base). Compare os parênteses na declaração de Jefferson citada na página 22.

6.6. A Objeção de Lady Lovelace

Nossa informação mais detalhada sobre a Máquina Analítica (Analytical Engine) de Babbage vem de um memorial (memoir) de Lady Lovelace (1842). Nele, ela afirma:

"A Máquina Analítica não tem pretensões de originar nada. Ela pode fazer qualquer coisa que saibamos como ordenar-lhe que execute" (itálicos dela).

Esta declaração é citada por Hartree (1949), que acrescenta:

"Isso não implica que não seja possível construir equipamentos eletrônicos que 'pensem por si mesmos', ou nos quais, em termos biológicos, se possa estabelecer um reflexo condicionado, que serviria como base para o 'aprendizado' (learning). Se isso é possível em princípio ou não, é uma questão estimulante e excitante, sugerida por alguns desses desenvolvimentos recentes. Mas não parecia que as máquinas construídas ou projetadas na época tivessem essa propriedade" (itálicos do tradutor).

Estou em total acordo com Hartree sobre isso. Note-se que ele não afirma que as máquinas em questão não tinham a propriedade, mas sim que a evidência disponível para Lady Lovelace não a encorajou a acreditar que a tivessem. É bem possível que as máquinas em questão, em certo sentido, tivessem essa propriedade. Pois suponha que alguma máquina de estados discretos tenha a propriedade. A Máquina Analítica era um computador digital universal, de modo que, se sua capacidade de armazenamento e velocidade fossem adequadas, ela poderia, por programação adequada, ser feita para imitar a máquina em questão. Provavelmente, este argumento não ocorreu à Condessa ou a Babbage. Em todo caso, não havia obrigação da parte deles de reivindicar tudo o que poderia ser reivindicado.

Toda esta questão será considerada novamente sob o título de máquinas que aprendem (learning machines).

Uma variante da objeção de Lady Lovelace afirma que uma máquina "nunca pode fazer nada realmente novo" (never do anything really new). Isso pode ser rebatido por um momento com o ditado: "Não há nada de novo debaixo do sol" (There is nothing new under the sun). Quem pode ter certeza de que o "trabalho original" que ele fez não foi simplesmente o crescimento da semente plantada nele pelo ensino, ou o efeito de seguir princípios gerais bem conhecidos? Uma variante melhor da objeção diz que uma máquina nunca pode "nos pegar de surpresa" (take us by surprise). Esta afirmação é um desafio mais direto e pode ser enfrentada diretamente.

As máquinas me pegam de surpresa com grande frequência. Isso ocorre em grande parte porque eu não faço cálculos suficientes para decidir o que esperar que elas façam, ou melhor, porque, embora eu faça um cálculo, eu o faço de forma apressada e desleixada (slipshod fashion), assumindo riscos. Talvez eu diga a mim mesmo: "Suponho que a tensão aqui deva ser a mesma que ali: de qualquer forma, vamos assumir que seja". Naturalmente, muitas vezes estou errado, e o resultado é uma surpresa para mim, pois no momento em que o experimento é feito, essas suposições já foram esquecidas. Essas admissões me expõem a sermões sobre meus métodos viciosos (vicious ways), mas não lançam qualquer dúvida sobre minha credibilidade quando testemunho as surpresas que experiencio.

Eu não espero que esta resposta silencie meu crítico. Ele provavelmente dirá que as surpresas se devem a algum ato mental criativo da minha parte, e não refletem nenhum mérito para a máquina. Isso nos leva de volta ao argumento da consciência, e para longe da ideia de surpresa. É uma linha de argumento que devemos considerar encerrada, mas talvez valha a pena notar que a apreciação de algo como surpreendente exige tanto um "ato mental criativo", quer o evento surpreendente se origine de um homem, de um livro, de uma máquina ou de qualquer outra coisa.

A visão de que máquinas não podem causar surpresas deve-se, creio eu, a uma falácia à qual filósofos e matemáticos estão particularmente sujeitos. Esta é a suposição de que, assim que um fato é apresentado a uma mente, todas as consequências desse fato brotam (spring into) na mente simultaneamente com ele. É uma suposição muito útil em muitas circunstâncias, mas esquece-se facilmente que ela é falsa. Uma consequência natural de fazer isso é que se assume, então, que não há virtude (virtue) no mero ato de extrair (working out) consequências a partir de dados e princípios gerais.

6.7. Argumento da Continuidade no Sistema Nervoso

O sistema nervoso certamente não é uma máquina de estados discretos. Um pequeno erro na informação sobre a magnitude de um impulso nervoso que incide sobre um neurônio pode fazer uma grande diferença na magnitude do impulso de saída. Pode-se argumentar que, sendo assim, não se pode esperar ser capaz de imitar o comportamento do sistema nervoso com um sistema de estados discretos.

É verdade que uma máquina de estados discretos deve ser diferente de uma máquina contínua. Mas se nos ativermos às condições do jogo da imitação, o interrogador não será capaz de tirar qualquer vantagem dessa diferença. A situação pode ser tornada mais clara se considerarmos alguma outra máquina contínua mais simples. Um analisador diferencial (differential analyser) servirá muito bem. (Um analisador diferencial é um certo tipo de máquina, não do tipo de estados discretos, usado para alguns tipos de cálculo.) Alguns destes fornecem suas respostas em forma datilografada (typed form), e assim são adequados para participar do jogo. Não seria possível para um computador digital prever exatamente quais respostas o analisador diferencial daria a um problema, mas ele seria perfeitamente capaz de dar o tipo certo de resposta. Por exemplo, se lhe pedissem para dar o valor de $\pi$ (na verdade, cerca de 3,1416), seria razoável escolher aleatoriamente entre os valores 3,12, 3,13, 3,14, 3,15, 3,16 com as probabilidades de 0,05, 0,15, 0,55, 0,19, 0,06 (digamos). Nessas circunstâncias, seria muito difícil para o interrogador distinguir o analisador diferencial do computador digital.

6.8. O Argumento da Informalidade do Comportamento

Não é possível produzir um conjunto de regras que pretenda descrever o que um homem deve fazer em cada conjunto concebível de circunstâncias. Poder-se-ia, por exemplo, ter uma regra que se deve parar quando se vê um semáforo vermelho, e seguir se vê um verde, mas e se, por alguma falha, ambos aparecerem juntos? Pode-se talvez decidir que é mais seguro parar. Mas alguma dificuldade adicional pode muito bem surgir dessa decisão mais tarde. Tentar fornecer regras de conduta para cobrir todas as eventualidades, mesmo aquelas decorrentes de semáforos, parece ser impossível. Com tudo isso eu concordo.

A partir disso, argumenta-se que não podemos ser máquinas. Tentarei reproduzir o argumento, mas temo que dificilmente lhe farei justiça. Parece ser algo assim:

"Se cada homem tivesse um conjunto definido de regras de conduta pelo qual regulasse sua vida, ele não seria melhor que uma máquina. Mas não existem tais regras, logo os homens não podem ser máquinas."

A falácia do termo médio não distribuído (undistributed middle) é gritante (glaring). Eu não acho que o argumento seja sempre apresentado exatamente assim, mas acredito que este seja, no entanto, o argumento usado.

Pode haver, no entanto, uma certa confusão entre "regras de conduta" (rules of conduct) e "leis de comportamento" (laws of behaviour) para turvar a questão. Por "regras de conduta" quero dizer preceitos como "Pare se vir luzes vermelhas", sobre os quais se pode agir, e dos quais se pode estar consciente. Por "leis de comportamento" quero dizer leis da natureza aplicadas ao corpo de um homem, tais como "se você o beliscar, ele gritará". Se substituirmos "leis de comportamento que regulam sua vida" por "regras de conduta pelas quais ele regula sua vida" no argumento citado, o termo médio não distribuído não é mais insuperável. Pois acreditamos que não só é verdade que ser regulado por leis de comportamento implica ser algum tipo de máquina (embora não necessariamente uma máquina de estados discretos), mas que, inversamente, ser tal máquina implica ser regulado por tais leis. No entanto, não podemos nos convencer tão facilmente da ausência de leis de comportamento completas como nos convencemos da ausência de regras de conduta completas. A única maneira que conhecemos para encontrar tais leis é a observação científica, e certamente não conhecemos nenhuma circunstância sob a qual poderíamos dizer: "Já procuramos o suficiente. Não existem tais leis."

Podemos demonstrar mais vigorosamente (forcibly) que qualquer declaração desse tipo seria injustificada. Pois, suponha que pudéssemos ter certeza de encontrar tais leis, se elas existissem. Então, dada uma máquina de estados discretos, deveria certamente ser possível descobrir por observação o suficiente sobre ela para prever seu comportamento futuro, e isso dentro de um tempo razoável, digamos, mil anos. Mas este não parece ser o caso. Eu configurei no computador de Manchester um pequeno programa usando apenas 1000 unidades de armazenamento, pelo qual a máquina, fornecida com um número de dezesseis dígitos, responde com outro em dois segundos. Eu desafiaria (defy) qualquer um a aprender com essas respostas o suficiente sobre o programa para ser capaz de prever quaisquer respostas para valores ainda não testados.

6.9. O Argumento da Percepção Extrassensorial

Presumo que o leitor esteja familiarizado com a ideia de percepção extrassensorial (ESP) e o significado de seus quatro itens, a saber, telepatia, clarividência, precognição e psicocinese. Esses fenômenos perturbadores parecem negar todas as nossas ideias científicas usuais. Como gostaríamos de desacreditá-los! Infelizmente, a evidência estatística, pelo menos para a telepatia, é esmagadora (overwhelming). É muito difícil reorganizar as próprias ideias de modo a encaixar esses novos fatos. Uma vez que se os aceita, não parece um passo muito grande acreditar em fantasmas e assombrações. A ideia de que nossos corpos se movem simplesmente de acordo com as leis conhecidas da física, juntamente com algumas outras ainda não descobertas, mas de alguma forma semelhantes, seria uma das primeiras a desaparecer.

Este argumento é, em minha opinião, bastante forte. Pode-se dizer em resposta que muitas teorias científicas parecem permanecer funcionais na prática, apesar de colidirem com a ESP; que, de fato, pode-se sair muito bem se nos esquecermos dela. Isso é um consolo bastante frio (rather cold comfort), e teme-se que o pensamento seja exatamente o tipo de fenômeno onde a ESP pode ser especialmente relevante.

Um argumento mais específico baseado na ESP poderia ser o seguinte:

"Vamos jogar o jogo da imitação, usando como testemunhas um homem que é bom como receptor telepático e um computador digital. O interrogador pode fazer perguntas como 'A qual naipe pertence a carta em minha mão direita?'. O homem, por telepatia ou clarividência, dá a resposta certa 130 vezes em 400 cartas. A máquina só pode adivinhar aleatoriamente, e talvez acerte 104, de modo que o interrogador faz a identificação correta."

Há uma possibilidade interessante que se abre aqui. Suponha que o computador digital contenha um gerador de números aleatórios. Então, será natural usá-lo para decidir que resposta dar. Mas, nesse caso, o gerador de números aleatórios estará sujeito aos poderes psicocinéticos do interrogador. Talvez essa psicocinese possa fazer com que a máquina acerte mais vezes do que o esperado em um cálculo de probabilidade, de modo que o interrogador ainda possa ser incapaz de fazer a identificação correta. Por outro lado, ele (o interrogador) poderia ser capaz de adivinhar corretamente sem qualquer questionamento, por clarividência. Com ESP, tudo pode acontecer.

Se a telepatia for admitida, será necessário tornar nosso teste mais rigoroso. A situação poderia ser considerada análoga à que ocorreria se o interrogador estivesse falando consigo mesmo e um dos competidores estivesse escutando com o ouvido colado à parede. Colocar os competidores em uma "sala à prova de telepatia" satisfaria todos os requisitos.

7. Máquinas que Aprendem (learning machines)

O leitor terá antecipado que não tenho argumentos muito convincentes de natureza positiva para apoiar minhas opiniões. Se eu os tivesse, não teria me dado a tanto trabalho para apontar as falácias nas visões contrárias. As evidências que tenho, apresentarei agora.

Voltemos por um momento à objeção de Lady Lovelace, que afirmava que a máquina só pode fazer o que lhe dizemos para fazer. Pode-se dizer que um homem pode "injetar" uma ideia na máquina, e que ela responderá até certo ponto e depois cairá em quiescência, como uma corda de piano golpeada por um martelo. Outra símile seria uma pilha atômica de tamanho inferior ao crítico: uma ideia injetada deve corresponder a um nêutron entrando na pilha vindo de fora. Cada nêutron desse tipo causará uma certa perturbação que eventualmente desaparece. Se, no entanto, o tamanho da pilha for suficientemente aumentado, a perturbação causada por tal nêutron de entrada muito provavelmente continuará crescendo e crescendo até que toda a pilha seja destruída. Existe um fenômeno correspondente para mentes, e existe um para máquinas? Parece haver um para a mente humana. A maioria delas parece ser "subcrítica", ou seja, corresponder nesta analogia a pilhas de tamanho subcrítico. Uma ideia apresentada a tal mente dará origem, em média, a menos de uma ideia em resposta. Uma pequena proporção é supercrítica. Uma ideia apresentada a tal mente pode dar origem a uma "teoria" inteira consistindo de ideias secundárias, terciárias e mais remotas. Mentes de animais parecem ser muito definitivamente subcríticas. Aderindo a esta analogia, perguntamos: "Pode uma máquina ser feita para ser supercrítica?"

A analogia da "casca de cebola" (skin-of-an-onion) também é útil. Ao considerar as funções da mente ou do cérebro, encontramos certas operações que podemos explicar em termos puramente mecânicos. Dizemos que isso não corresponde à mente real: é uma espécie de "casca" (skin) que devemos remover se quisermos encontrar a mente real. Mas então, no que resta, encontramos uma casca adicional a ser removida, e assim por diante. Procedendo dessa forma, chegamos alguma vez à mente "real", ou eventualmente chegamos a uma casca que não tem nada dentro? Neste último caso, toda a mente é mecânica. (Não seria, contudo, uma máquina de estados discretos. Já discutimos isso.)

Estes dois últimos parágrafos não pretendem ser argumentos convincentes. Eles deveriam ser descritos antes como "recitações que tendem a produzir crença".

O único apoio realmente satisfatório que pode ser dado à visão expressa no início do §6 será aquele fornecido pela espera até o final do século e, então, pela realização do experimento descrito. Mas o que podemos dizer enquanto isso? Que passos devem ser dados agora para que o experimento seja bem-sucedido?

Como expliquei, o problema é principalmente de programação (programming). Avanços na engenharia terão que ser feitos também, mas parece improvável que estes não sejam adequados para os requisitos. As estimativas da capacidade de armazenamento do cérebro variam de $10^{10}$ a $10^{15}$ dígitos binários. Eu me inclino para os valores mais baixos e acredito que apenas uma fração muito pequena é usada para os tipos mais elevados de pensamento. A maior parte dela é provavelmente usada para a retenção de impressões visuais. Eu ficaria surpreso se mais de $10^9$ fosse necessário para jogar satisfatoriamente o jogo da imitação, pelo menos contra um homem cego. (Nota: A capacidade da Encyclopaedia Britannica, 11ª edição, é $2 \times 10^9$). Uma capacidade de armazenamento de $10^7$ seria uma possibilidade muito praticável mesmo com as técnicas atuais. Provavelmente não é necessário aumentar de todo a velocidade das operações das máquinas. Partes das máquinas modernas que podem ser consideradas como análogos das células nervosas trabalham cerca de mil vezes mais rápido que estas últimas. Isso deve fornecer uma "margem de segurança" que poderia cobrir perdas de velocidade decorrentes de muitas maneiras. Nosso problema, então, é descobrir como programar (to programme) essas máquinas para jogar o jogo. No meu ritmo atual de trabalho, eu produzo cerca de mil dígitos de programa (programme) por dia, de modo que cerca de sessenta trabalhadores, trabalhando continuamente ao longo dos cinquenta anos, poderiam realizar o trabalho, se nada fosse para a cesta de lixo. Algum método mais expedito (expeditious) parece desejável.

No processo de tentar imitar uma mente humana adulta, somos forçados a pensar bastante sobre o processo que a levou ao estado em que se encontra. Podemos notar três componentes.

1. O estado inicial da mente, digamos, no nascimento,

2. A educação à qual ela foi submetida,

3. Outras experiências, que não podem ser descritas como educação, às quais ela foi submetida.

Em vez de tentar produzir um programa que simule a mente adulta, por que não tentar, em vez disso, produzir um que simule a da criança? Se este fosse então submetido a um curso apropriado de educação, obter-se-ia o cérebro adulto. Presumivelmente, o cérebro da criança é algo como um caderno que se compra na papelaria: pouco mecanismo, e muitas folhas em branco. (Mecanismo e escrita são, do nosso ponto de vista, quase sinônimos.) Nossa esperança é que haja tão pouco mecanismo no cérebro da criança que algo semelhante possa ser facilmente programado. A quantidade de trabalho na educação podemos assumir, como uma primeira aproximação, ser muito parecida com a de uma criança humana.

Dividimos, assim, nosso problema em duas partes. O programa-criança (child programme) e o processo educacional. Estes dois permanecem muito intimamente conectados. Não podemos esperar encontrar uma boa máquina-criança (child machine) na primeira tentativa. Deve-se experimentar ensinar uma tal máquina e ver quão bem ela aprende. Pode-se então tentar outra e ver se é melhor ou pior. Há uma conexão óbvia entre este processo e a evolução, pelas identificações:

• Estrutura da máquina-criança = material hereditário

• Mudanças da máquina-criança = mutação

• Seleção natural = julgamento do experimentador

Pode-se esperar, contudo, que este processo seja mais expedito (expeditious) que a evolução. A sobrevivência do mais apto é um método lento para medir vantagens. O experimentador, pelo exercício da inteligência, deveria ser capaz de acelerá-lo. Igualmente importante é o fato de que ele não está restrito a mutações aleatórias. Se ele puder rastrear a causa de alguma fraqueza, ele provavelmente poderá pensar no tipo de mutação que a melhorará.

Não será possível aplicar exatamente o mesmo processo de ensino à máquina como a uma criança normal. Ela não será, por exemplo, provida de pernas, de modo que não se poderia pedir-lhe para sair e encher o balde de carvão. Possivelmente ela poderia não ter olhos. Mas por melhor que essas deficiências pudessem ser superadas por engenharia inteligente, não se poderia mandar a criatura para a escola sem que as outras crianças zombassem dela excessivamente. Ela deve receber alguma instrução. Não precisamos nos preocupar muito com as pernas, olhos, etc. O exemplo da Srta. Helen Keller mostra que a educação pode ocorrer, desde que a comunicação em ambas as direções, entre professor e aluno, possa ocorrer por um meio ou outro.

Normalmente associamos punições (punishments) e recompensas (rewards) ao processo de ensino. Algumas máquinas-criança simples podem ser construídas ou programadas com base nesse tipo de princípio. A máquina tem que ser construída de tal forma que eventos que precederam em pouco tempo (shortly preceded) a ocorrência de um sinal de punição (punishment signal) sejam improváveis de se repetir, enquanto um sinal de recompensa (reward signal) aumente a probabilidade de repetição dos eventos que levaram a ele. Essas definições não pressupõem quaisquer sentimentos por parte da máquina. Eu fiz alguns experimentos com uma dessas máquinas-criança, e consegui ensiná-la algumas coisas, mas o método de ensino foi muito pouco ortodoxo para que o experimento fosse considerado realmente bem-sucedido.

O uso de punições e recompensas pode, na melhor das hipóteses, ser uma parte do processo de ensino. Grosso modo, se o professor não tem outros meios de se comunicar com o aluno, a quantidade de informação que pode alcançá-lo não excede o número total de recompensas e punições aplicadas. Até que uma criança aprendesse a repetir o poema "Casabianca", ela provavelmente se sentiria muito dolorida (very sore), se o texto só pudesse ser descoberto por uma técnica de "Vinte Perguntas", onde cada "NÃO" tomasse a forma de um golpe. É necessário, portanto, ter alguns outros canais "não emocionais" (unemotional) de comunicação. Se estes estiverem disponíveis, é possível ensinar uma máquina, por punições e recompensas, a obedecer a ordens dadas em alguma linguagem, por exemplo, uma linguagem simbólica. Essas ordens devem ser transmitidas através dos canais "não emocionais". O uso dessa linguagem diminuirá muito o número de punições e recompensas necessárias.

As opiniões podem variar quanto à complexidade adequada na máquina-criança. Pode-se tentar torná-la o mais simples possível, de forma consistente com os princípios gerais. Alternativamente, pode-se ter um sistema completo de inferência lógica "embutido". Neste último caso, a memória (store) estaria largamente ocupada com definições e proposições. As proposições teriam vários tipos de status, por exemplo, fatos bem estabelecidos, conjecturas, teoremas matematicamente provados, declarações dadas por uma autoridade, expressões com a forma lógica de proposição, mas sem valor-crença (belief-value). Certas proposições podem ser descritas como "imperativos" (imperatives). A máquina deve ser construída de tal forma que, assim que um imperativo for classificado como "bem estabelecido", a ação apropriada ocorra automaticamente. Para ilustrar isso, suponha que o professor diga à máquina: "Faça seu dever de casa agora". Isso pode fazer com que "O professor diz 'Faça seu dever de casa agora'" seja incluído entre os fatos bem estabelecidos. Outro fato desse tipo poderia ser: "Tudo o que o professor diz é verdade". A combinação destes pode, eventualmente, levar ao imperativo "Faça seu dever de casa agora" ser incluído entre os fatos bem estabelecidos; e isso, pela construção da máquina, significará que o dever de casa realmente é iniciado, mas o efeito é muito satisfatório. Os processos de inferência usados pela máquina não precisam ser tais que satisfaçam os lógicos mais exigentes. Poderia, por exemplo, não haver hierarquia de tipos. Mas isso não significa necessariamente que falácias de tipo (type fallacies) ocorrerão, assim como não estamos fadados a cair de penhascos sem cerca. Imperativos adequados (expressos dentro dos sistemas, não formando parte das regras do sistema) tais como "Não use uma classe a menos que seja uma subclasse de uma que tenha sido mencionada pelo professor" podem ter um efeito similar a "Não chegue muito perto da borda".

Os imperativos que podem ser obedecidos por uma máquina que não tem membros estão fadados a ser de um caráter bastante intelectual, como no exemplo (fazer o dever de casa) dado acima. Importantes entre tais imperativos serão aqueles que regulam a ordem em que as regras do sistema lógico em questão devem ser aplicadas. Pois, em cada estágio, quando se está usando um sistema lógico, há um número muito grande de passos alternativos, qualquer um dos quais se é permitido aplicar, no que diz respeito à obediência às regras do sistema lógico. Essas escolhas fazem a diferença entre um raciocinador brilhante (brilliant) e um fútil (footling), não a diferença entre um raciocinador sólido (sound) e um falacioso (fallacious). Proposições que levam a imperativos desse tipo podem ser:

"Quando Sócrates for mencionado, use o silogismo em Barbara"

ou

"Se um método provou ser mais rápido que outro, não use o método mais lento."

Alguns destes podem ser "dados por autoridade" (given by authority), mas outros podem ser produzidos pela própria máquina, por exemplo, por indução científica.

A ideia de uma máquina que aprende (learning machine) pode parecer paradoxal para alguns leitores. Como podem as regras de operação da máquina mudar? Elas deveriam descrever completamente como a máquina reagirá, qualquer que seja seu histórico, quaisquer que sejam as mudanças pelas quais ela passe. As regras são, assim, bastante invariantes no tempo. Isso é bem verdade. A explicação do paradoxo é que as regras que são alteradas no processo de aprendizado são de um tipo um tanto menos pretensioso, reivindicando apenas uma validade efêmera. O leitor pode traçar um paralelo com a Constituição dos Estados Unidos.

Uma característica importante de uma máquina que aprende é que seu professor será, muitas vezes, em grande parte ignorante do que exatamente está acontecendo lá dentro, embora ele ainda possa ser capaz, em certa medida, de prever o comportamento de seu pupilo. Isso deve se aplicar mais fortemente à educação posterior de uma máquina originada de uma máquina-criança (child machine) de uma arquitetura ou programa (design or programme) bem testados. Isso está em claro contraste com o procedimento normal ao usar uma máquina para fazer computações: o objetivo de alguém é, então, ter uma imagem mental clara do estado da máquina a cada momento da computação. Esse objetivo só pode ser alcançado com esforço (struggle). A visão de que "a máquina só pode fazer o que sabemos como ordenar-lhe que faça" parece estranha em face disso. A maioria dos programas que podemos colocar na máquina resultará em ela fazendo algo do qual dificilmente extraimos sentido (se é que conseguimos), ou que consideramos como comportamento completamente aleatório. O comportamento inteligente presumivelmente consiste em um desvio do comportamento completamente disciplinado envolvido na computação, mas um desvio bastante sutil (slight), que não dê origem a comportamento aleatório, ou a laços (loops) repetitivos sem sentido. Outro resultado importante de preparar nossa máquina para seu papel no jogo da imitação por um processo de ensino e aprendizado é que a "falibilidade humana" (human fallibility) é provavelmente imitada (imitated) de uma forma bastante natural, ou seja, sem "treinamento" (coaching) especial. (O leitor deve reconciliar isso com o ponto de vista das páginas 23 e 24.) Processos que são aprendidos não produzem cem por cento de certeza no resultado; se o fizessem, não poderiam ser desaprendidos (unlearnt).

É provavelmente sensato incluir um elemento aleatório em uma máquina que aprende. Um elemento aleatório é bastante útil quando estamos procurando a solução de algum problema. Suponha, por exemplo, que quiséssemos encontrar um número entre 50 e 200 que fosse igual ao quadrado da soma de seus dígitos; poderíamos começar em 51, depois tentar 52 e continuar até encontrar um número que funcionasse. Alternativamente, poderíamos escolher números aleatoriamente até encontrar um bom. Este método tem a vantagem de que não é necessário manter um registro dos valores que foram tentados, mas a desvantagem de que se pode tentar o mesmo valor duas vezes, mas isso não é muito importante se houver várias soluções. O método sistemático tem a desvantagem de que pode haver um bloco enorme sem nenhuma solução na região que deve ser investigada primeiro. Ora, o processo de aprendizado pode ser considerado como uma busca (search) por uma forma de comportamento que satisfaça o professor (ou algum outro critério). Como provavelmente existe um número muito grande de soluções satisfatórias, o método aleatório parece ser melhor que o sistemático. Deve-se notar que ele é usado no processo análogo da evolução. Mas lá o método sistemático não é possível. Como se poderia manter um registro das diferentes combinações genéticas que foram tentadas, de modo a evitar tentá-las novamente?

Podemos esperar que as máquinas eventualmente compitam com os homens em todos os campos puramente intelectuais. Mas com quais é melhor começar? Mesmo esta é uma decisão difícil. Muitas pessoas pensam que uma atividade muito abstrata, como jogar xadrez, seria o melhor. Pode-se também sustentar que é melhor fornecer à máquina os melhores órgãos dos sentidos (sense organs) que o dinheiro pode comprar, e então ensiná-la a entender e falar inglês. Este processo poderia seguir o ensino normal de uma criança. Coisas seriam apontadas e nomeadas, etc. Novamente, não sei qual é a resposta certa, mas acho que ambas as abordagens deveriam ser tentadas.

Só podemos ver a uma curta distância à frente, mas vemos claramente que há muito a ser feito. (We can only see a short distance ahead, but we can see plenty there that needs to be done.)

TURING, A. M. Computing Machinery and Intelligence. Mind, Oxford, v. 59, n. 236, p. 433-460, out. 1950. DOI: 10.1093/mind/LIX.236.433.

O cliente recebia, diariamente, milhares de editais de licitação que precisavam ser classificados por tipo de serviço. O processo manual era tecnicamente complexo, lento e sujeito à fadiga cognitiva dos especialistas.

O objetivo era automatizar esse processo com IA, e 3 requisitos estavam claros:

1. baixo custo operacional;

2. alta aderência à expertise humana (precisão); e

3. determinismo (previsibilidade e explicabilidade das decisões).

A armadilha

A tentação imediata seria utilizar um modelo como GPT ou Gemini para fazer as classificações. Essa abordagem, aparentemente moderna e sofisticada, rapidamente se revelaria ingênua — uma flagrante engenharia excessiva e em conflito com todos os requisitos do cliente.

É fato que os LLMs são o estado da arte na compreensão de texto. Mas o outro lado da moeda, a etapa generativa, apresenta:

• custo extremo;

• pré-treinamento genérico e alheio à expertise humana; e, portanto,

• comportamento imprevisível em domínios específicos.

Ou seja: alto custo, baixa aderência e pouca previsibilidade. Trágico!

O "pulo do gato"

Felizmente, todo o poder de compreensão de um LLM reside em seu engenhoso "Transformer", que mapeia o texto em um espaço vetorial semântico. Enquanto os detalhes técnicos podem ser consultados no artigo intitulado “Attention Is All You Need” (Vaswani et al., 2017), os provedores comerciais de LLM fornecem essa transformação com desempenho excepcional e custo reduzido por meio de suas API.

Assim, podemos desfrutar de uma compreensão semântica de altíssima qualidade, enquanto evitamos a caríssima etapa de geração, substituindo-a completamente por um modelo adequado ao problema.

Para a classificação, os experimentos da modelagem corroboraram o bom desempenho das Redes Neurais Artificiais, o que já era indicado pela experiência. Assim, essa arquitetura foi utilizada para desenvolver um modelo e treiná-lo sobre o conjunto de dados do cliente, composto por milhares de licitações previamente classificadas manualmente.

Resultados

Como esperávamos, essa arquitetura híbrida foi um sucesso, alcançando um classificador com a mesma capacidade interpretativa de um LLM comercial e com a mesma estratégia de classificação do especialista humano.

A escolha do classificador adequado permitiu uma redução brutal do número de parâmetros envolvidos na etapa de classificação (e, por conseguinte, de sua complexidade): em vez dos bilhões (e, por vezes, trilhões!) de parâmetros de um LLM comercial de propósito geral, utilizamos apenas algumas centenas de neurônios e uma arquitetura surpreendentemente mais simples.

Por fim, a arquitetura completa foi:

1. Compreensão (embedding de Transformer via API);

2. Classificação (RNA própria).

Dada a simplicidade do classificador e considerando a total viabilidade de sua execução na infraestrutura atual do cliente sem custos adicionais, podemos considerar que o custo operacional final é igual ao custo da etapa de compreensão (isto é, da API de embedding).

Considerando-se a aproximação 3 caracteres ≈ 1 token, o tamanho médio aproximado dos objetos licitatórios é de 70 tokens. Para 10 mil documentos, temos 700.000 tokens*. Com um custo de US$ 0,15 por milhão de tokens e a cotação do dólar a R$ 5,38, temos que *o custo final (estimado) para 10.000 documentos é de, aproximadamente, R$ 0,54!

Conclusões

Este projeto foi um case clássico de que, em Machine Learning, a melhor solução não é a maior ou mais nova tecnologia, mas aquela que resolve a dor do cliente de forma precisa, controlada e economicamente viável.

Às vezes, a verdadeira inovação está em saber o que NÃO usar.

Postado originalmente no LinkedIn.

O desafio, portanto, não é técnico, mas cultural. Exige que o pesquisador veja o código não como um rascunho descartável, mas como um ativo de pesquisa primário, tão duradouro e auditável quanto uma amostra de laboratório ou um dado de campo. Adotar ferramentas de controle de versão como o Git não é aprender a programar melhor; é praticar ciência de forma mais rigorosa.

“Qualquer tolo pode escrever código que um computador entende. Bons programadores escrevem código que humanos entendem.” — Martin Fowler (tradução livre)

Se a pasta do seu projeto contém arquivos como analise_final.py, analise_final_revisada.py e o desesperado analise_final_agora_vai.py, você não está sozinho. Se a sua colaboração se parece com uma troca de e-mails com anexos codigo_v2_comentarios_joao.zip, saiba que essa é a norma em muitos departamentos. Mas essa prática, embora comum, representa um dos maiores e mais silenciosos riscos à integridade do trabalho científico moderno.

Reprodutibilidade em computação científica

Enquanto você lê este artigo, economistas escrevem programas para simular o comportamento dos mercados; químicos e farmacêuticos escrevem código que prevê a eficácia de fármacos que ainda nem existem; biólogos ou cientistas sociais analisam grandes volumes de dados para encontrar padrões ocultos nos seus respectivos objetos de estudo…

Mesmo áreas tradicionalmente distantes da computação incorporam cada vez mais ferramentas computacionais em suas metodologias centrais. Para muitos pesquisadores nessas áreas, a programação não é vocação ou interesse principal, mas sim ferramenta necessária para responder às questões científicas que os motivam.

Exemplo: O que pode dar errado?

Aprecie a seguir a história da doutoranda Ana Ribeiro, que facilmente suscitará identificação no leitor.

Após incansáveis anos de trabalho, a pesquisadora Ana Ribeiro, doutoranda em neurociência computacional, finalmente submeteu um artigo promissor com seu modelo de rede neural para simular a tomada de decisão. Enquanto aguardava a resposta dos revisores, seu orientador, empolgado com os resultados, propôs duas novas e ousadas hipóteses para expandir o trabalho: uma envolvendo um mecanismo de "atenção seletiva" e outra, uma forma de "plasticidade sináptica" mais complexa.

Empolgada, Ana mergulhou de cabeça no desenvolvimento. A pasta do projeto logo se tornou um labirinto de arquivos como modelo_v2_atencao.py e modelo_v3_plasticidade_teste.py, com funções sendo reescritas e parâmetros sendo ajustados constantemente em múltiplas versões divergentes, sem um registro claro do que pertencia a qual experimento. Felizmente, as duas hipóteses forneceram resultados promissores que certamente integrariam sua tese.

Três meses depois, enquanto já preparava outro artigo com seus novos resultados, o e-mail que ela tanto esperava chegou. Eram boas notícias: o artigo anterior fora aceito com revisões menores. No entanto, uma das solicitações era aparentemente simples: "Poderia a autora rodar novamente a simulação da Figura 3, mas alterando um parâmetro de entrada, para validar a robustez do resultado?".

O que deveria ser uma tarefa de minutos se transformou em pânico! O código exato que gerou aquela figura não existia mais em sua forma original; ele havia sido canibalizado e modificado para os novos experimentos. Diante da confusão de arquivos, ela não conseguia garantir qual versão era a correta, tornando impossível atender ao pedido do revisor com integridade científica e colocando em risco a publicação de todo o seu trabalho.

A história de Ana é uma ficção, mas a tragédia vivida por ela se situa nas proximidades da dura realidade de inúmeros pós-graduandos e pesquisadores — mais do que gostaríamos de admitir.

Se Ana tivesse usado Git, a versão submetida estaria marcada por uma tag ou seria facilmente recuperável pelo commit relacionado, criando um registro permanente e imutável. As novas e empolgantes hipóteses seriam exploradas em ramificações paralelas (branches), sem jamais tocar na versão "oficial" do artigo. O pedido do revisor seria atendido com a confiança e o rigor que a ciência exige, em vez de se tornar uma crise que ameaçava meses de trabalho.

O código é a metodologia

O código que produz um resultado científico não é mero subproduto da pesquisa; constitui a especificação exata e inequívoca de como os dados foram transformados em conclusões, carregando, em si próprio, a reprodutibilidade do trabalho. O código se torna a própria metodologia.

Nenhum pesquisador sério publicaria resultados experimentais sem documentar meticulosamente os procedimentos utilizados. Cadernos de laboratório registram todos os detalhes técnicos e observações relevantes para o trabalho. Essa documentação permite que o pesquisador original reconstrua o que foi feito meses ou anos depois, e permite que outros pesquisadores tentem replicar os resultados independentemente.

A lógica subjacente é tão fundamental à prática científica que raramente é questionada. Registrar todas as alterações do código-fonte ao longo de um projeto de pesquisa, documentar qual versão foi utilizada para gerar cada resultado, e manter histórico completo do desenvolvimento computacional são práticas de mesma natureza e mesma importância.

A reprodutibilidade não é um detalhe técnico ou uma virtude periférica — é a linha que distingue a ciência da opinião. Se um pesquisador não consegue recuperar a versão precisa do código que gerou os resultados de um artigo, esses resultados, estritamente falando, não são mais reprodutíveis. Um trabalho que não pode ser verificado por terceiros não pode servir como uma fundação confiável para a construção de novo conhecimento.

Modificar código sem documentar a mudança é equivalente a alterar um procedimento experimental sem registrar a alteração. Usar uma versão diferente do código sem a identificar claramente é equivalente a trocar um reagente químico sem anotá-lo. Perder o histórico de desenvolvimento do código é equivalente a rasgar páginas do caderno de laboratório.

A solução pragmática

Para a implementação do versionamento de código, serão mínimas as mudanças na sua rotina — mas elas te forçarão a trabalhar de forma organizada. Utilizaremos duas ferramentas, gratuitas e complementares, que são o padrão absoluto no mundo hoje. Tratam-se do Git e do GitHub.

O Git é um sistema de controle de versões (VCS) distribuído, ou seja, a ferramenta responsável por registrar e gerenciar toda a sequência de alterações do projeto desde a sua criação, e resolver conflitos entre diferentes versões existentes. Além disso, ele é capaz de reconstruir o estado exato do código-fonte em qualquer versão disponível. É uma ferramenta livre desenvolvida por Linus Torvalds, desenvolvedor do kernel Linux.

Já o GitHub é a central que armazenará seu projeto e o histórico do Git, permitindo a colaboração entre diferentes pessoas/máquinas ou simplesmente garantindo que seu projeto esteja sempre acessível. É um serviço gratuito adquirido pela Microsoft.

Em suma, você utiliza o Git para registrar as alterações no seu projeto local e para sincronizá-las com o GitHub.

No próximo artigo desta série, aprofundaremos no modelo mental adequado aos pesquisadores que desejam versionar seu código-fonte.

Este tutorial foi feito utilizando-se o ChemDraw 16.0, Wine 5.0 e Ubuntu 20.04.

Um pouco de vinho: Wine

O Wine (sigla recursiva para Wine Is Not an Emulator) é uma camada de compatibilidade para a execução em sistemas Unix de programas desenvolvidos para Windows. Para instalá-lo, siga as instruções oficiais para sua distribuição.

Escolha um diretório para armazenar os arquivos relacionados ao Windows. O padrão é ~/.wine e é o que será utilizado. Altere como quiser. Abra um terminal e execute os seguintes comandos:

export WINEPREFIX=~/.wine
export WINEARCH=win32

Utilize a mesma instância do terminal até o fim do tutorial. Caso precise criar uma nova, rode esses comandos novamente. Execute agora:

winecfg

Você deverá ver, em ~/.wine/dosdevices/, as unidades normalmente encontradas no sistema da Microsoft.

Truques de bar: winetricks

Winetricks é um script auxiliar do Wine para a instalação de dependências do mundo Windows. Instale-o seguindo as instruções oficiais. Se você seguiu essas instruções corretamente, estará agora em ~/Downloads/ e poderá acessar o arquivo winetricks. Execute o seguinte comando no terminal (se ainda não tiver feito):

chmod +x winetricks

Instalando algumas dependências

Você precisará instalar três dependências que não são distribuídas por padrão com o Wine. São elas:

• dotnet40
• gdiplus
• vcrun2013

Instale-as com o seguinte comando no terminal, de dentro da pasta do winetricks:

./winetricks dotnet40 gdiplus vcrun2013

Aguarde alguns minutos enquanto a instalação acontece. Siga as instruções nas interfaces Windows-like que serão mostradas.

Instalando o software

Visite o site oficial e faça o download para Windows de sua cópia do programa. Escolha entre comprar agora ou fazer um teste gratuito. Com sua cópia baixada, use o terminal para visitar a pasta que contém o instalador .msi (se necessário, descompacte o arquivo). Supondo que o tenha baixado em ~/Downloads/ChemDraw/, faça:

cd ~/Downloads/ChemDraw/

Execute o seguinte (lembre-se de corrigir o nome do arquivo ou começar a digitar e teclar "tab" para completar automaticamente):

wine msiexec /i "Nome do arquivo.msi"

Você verá um instalador muito semelhante ao do Windows e poderá fazer a instalação como de costume. Os ícones dos programas instalados aparecerão no seu menu e funcionarão quase como programas nativos.

Antes de tudo, aos colegas que utilizam Linux religiosamente, também é possível fazer isso, usando outras bibliotecas e outro método. Não vou apresentar aqui porque o Linux (ao menos meu Ubuntu 20.04) é inteligente o suficiente para fazer isso out of the box durante a inicialização...

Isto posto, vamos aos trabalhos.

Um pouco de pesquisa

Diferente do que quem está começando a programar pode pensar, poucos programadores de fato sabem fazer qualquer coisa sem nenhuma consulta à internet. A verdade é que, como programadores, devemos saber descobrir de maneira efetiva a melhor forma de fazer algo, ter intuição e etc. Sendo assim, eu não sabia exatamente como definir a hora do Windows no Python. Eu já sabia que precisaria obter a hora de algum lugar, mas também não tinha decidido de onde.

Para começar a brincadeira, fui à internet procurar algumas bibliotecas que poderiam facilitar meu trabalho de definir a hora do sistema. Encontrei uma lib chamada pywin32 que permite, entre outras coisas, definir a hora do sistema. A forma como ela faz isso é a seguinte:

# Sim, o import é diferente do nome canônico da biblioteca...
import win32api

# A hora deve ser atribuída em fuso UTC (ou GMT, a hora do pacífico).
# O fuso horário correto é definido nas configurações do sistema operacional.
win32api.SetSystemTime(year, month, weekday, day, hour, minutes, seconds, milliseconds)

Ótimo. Agora eu só precisava obter a hora correta na internet. A ideia inicial foi entrar em algum site oficial e usar web scraping para obter a hora atual. Como eu falei acima sobre intuição, um alerta piscante surgiu imediatamente na minha cabeça dizendo overengineering (engenharia excessiva, tipo construir uma ponte Rio-Niterói para um carrinho de controle remoto: funciona, mas não é uma boa ideia). Provavelmente existia alguma API pra obter isso, me restando apenas uma pesquisa decente e uma linha de código. Como em qualquer dia normal, caí no StackOverflow e encontrei um serviço que retorna nada mais que a hora atual em formato ISO (esse formato da imagem abaixo). Perfeito! Era exatamente o que eu queria.

Usando um parâmetro get ?f= também é possível obter a data em outros formatos, mas não vem ao caso.

Com isso tudo em mãos, bastava obter a hora (e já sabemos como), definir no sistema operacional (o que também sabemos como) e fazer isso inicializar com o sistema (isso a gente resolve mais tarde hehe).

Coding time

Abaixo o código comentado de como fiz as duas primeiras coisas.

import os
from datetime import datetime
import urllib3
import win32api
import logging

# Fazemos a requisição aqui
response = urllib3.PoolManager().request('GET', "http://just-the-time.appspot.com")

# Se o status HTTP não for 200 (OK), paramos tudo.
if response.status != 200:
    logging.error(f"Server responded with status {response.status}.")
    os.exit(1)

# Agora que sabemos que o status code é 200, isso significa que response.data contém o
# corpo do retorno da página. No caso, apenas a data e a hora no formato iso.
# Vamos obtê-las separadas
date, time = response.data.decode('utf-8').strip().split(' ')

# E agora obtemos cada parâmetro, convertemos para inteiro e
# atribuímos a novas variáveis
hour, minutes, seconds = list(map(int, time.split(':')))
year, month, day =  list(map(int, date.split('-')))

# Precisamos calcular o dia da semana com o datetime e vamos
# deixar os milissegundos em zero mesmo.
time_tuple = (
    year,
    month,
    datetime(year, month, day).weekday(),
    day,
    hour,
    minutes,
    seconds,
    0
)

# A grande "hora" (haha)
win32api.SetSystemTime(*time_tuple)

A última linha, se você não está acostumadx com Python, está "desestruturando" a tupla e passando cada elemento como um argumento. Por exemplo, as duas chamadas de funções a seguir são idênticas:

def soma(a: float, b: float) -> float:
    return a + b


# As duas chamadas abaixo fazem exatamente a mesma coisa.
soma(a, b)
soma(*(a, b))

Para alterar a hora do sistema, é necessário obter permissões elevadas. Isso significa que você deve executar seu Terminal como administrador (para o cmd.exe, tecle Win + R, digite cmd e tecle Ctrl + Shift + Alt + Enter e dê a permissão).

Criando um executável

Para criar um executável que funcione standalone, sem precisar executar via linha de comando, podemos usar o pyinstaller, biblioteca muito simples de usar. Para criar um executável a partir do arquivo principal main.py, tudo o que precisamos é fazer o seguinte na linha de comando (permissões elevadas podem ser necessárias):

> cd seu_diretorio\
> pip install pyinstaller
> pyinstaller main.py --onefile --uac-admin

Isso vai instalar o pyinstaller (como num Inception, tipo usar o Explorer pra baixar o Chrome) e criar um único executável (--onefile) que exige permissões administrativas (--uac-admin) a partir de main.py, que é o arquivo de entrada (nesse caso, o único) do nosso programa. Você pode definir outras opções. Acesse a documentação oficial para ver quais estão disponíveis.

Acesse a pasta dist\, copie seu executável e mova para algum lugar de seu interesse (ou deixe aí mesmo). Eu coloquei em C:\Program Files\current_hour_setter\current_hour_setter.exe.

Inicializando tudo com o Windows

Essa é talvez a parte mais demorada. Vamos criar uma tarefa no agendador de tarefas do Windows que executa um prompt de comando com permissões administrativas e, daí, executa nosso executável com as permissões corretas. Em seguida, vamos fazer isso ser executado junto com o sistema.

Executando o programa com permissões administrativas sem o prompt

O que faremos aqui é executar o nosso script com permissão administrativa sem passar pelo popup típico de permissão do Windows (UAC credential prompt). Esse procedimento foi obtido em um fórum (em inglês) que também apresenta um método automático usando um arquivo bat. Eu, no entanto, não recomendo (e não fiz). O método manual segue.

1. Aperte Win + R e digite taskschd.msc, confirmando em seguida.

2. Clique em Biblioteca do Agendador

3. Clique em Criar Tarefa...

4. Em Nome, coloque um nome para a sua tarefa (e anote). Em Descrição, faça o mesmo. Marque a caixa "Executar com privilégios mais altos" e defina "Configurar para: Windows 10".

5. Clique na guia Ações e no botão Novo... Na janela que abrir, defina o Programa/Script como cmd.exe.

Assim, estamos criando uma tarefa que executa um cmd.exe com permissões elevadas.

6. Vamos também executar nosso script. Adicione, no campo "Adicione argumentos (opcional)", o seguinte:

/c start "Nome da Tarefa" "C:\Program Files\current_hour_setter\current_hour_setter.exe"

No lugar de "Nome da Tarefa", coloque o nome da tarefa definido no passo 4. Substitua o caminho para o caminho do seu executável. Clique em OK quantas vezes forem necessário e feche o agendador de tarefas (mantendo o nome da sua tarefa anotado).

Agora temos uma tarefa que abre um prompt de comando elevado e executa o nosso executável com as mesmas permissões.

Executando tudo na inicialização do sistema

7. Clique com o botão direito no seu desktop ou em alguma pasta vazia, vá até Novo... e clique Atalho.

8. No endereço, coloque o seguinte, substituindo o nome da tarefa pelo correto. schtasks /run /tn "Nome da Tarefa"

9. Salve com um nome adequado.

10. Mova esse atalho para a pasta de inicialização do Windows.

• Para fazer isso apenas no usuário atual, mova para: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

• Para fazer isso para todos os usuários do sistema, mova para: %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\StartUp

Deixe seu sistema com a hora incorreta e reinicie. Se tudo deu certo, seu relógio deve ser corrigido alguns segundos após a inicialização.

Conclusão

Esta foi uma tentativa de mostrar como a programação não é algo exatamente complicado (configurar o Windows foi bem mais trabalhoso) e também como pode ser feito para resolver problemas reais na vida.

Se você quer começar a programar, confira meu curso de Algoritmos com Portugol Studio no Youtube.

Verapamil, sold under various trade names, is a medication used for the treatment of high blood pressure, angina (chest pain from not enough blood flow to the heart), and supraventricular tachycardia.
Know more: https://t.co/edylwYnoNW pic.twitter.com/zwGlehCyUF

— Tweemol (@tweemol) July 18, 2020

Neste post, vou explicar como desenvolvi isso e como você pode fazer o seu também. De preferência, aventure-se com APIs diferentes das que usei, ou escolha publicar em outra rede. Isso vai evitar que você apenas siga um tutorial e realmente desenvolva o seu projeto. Antes de tudo, quero adiantar que este projeto é relativamente grande. Tem MUITA coisa que precisamos discutir em detalhes aqui. Recomendo ler uma vez e partir para o seu projeto, consultando novamente no momento sentir que não está avançando mais. Então vamos lá.

Escolhendo tecnologias

Se você esta desenvolvendo um projeto real que vai para produção (momento em que o projeto já está funcionando com usuários reais, diferente do estágio de desenvolvimento), o ideal é escolher a tecnologia baseado nas especificidades do negócio, na necessidade de performance, produtividade da equipe, maturidade da tecnologia, suporte, facilidade de contratar profissionais, dentre diversos outros fatores. Ao desenvolver um projeto para estudo, no entanto, a coisa muda um pouco de figura: nesse caso, eu já recomendo escolher tecnologias que não estejam na sua zona de conforto, ou que sejam novas, para garantir que você esteja aprendendo algo.

Quando desenvolvi este projeto, eu ainda não tinha muito costume com o Node.js e queria me aprofundar um pouco. Isso me fez escolher essa tecnologia. Mais tarde, escolhi Python para desenvolver outro projeto (que posso trazer aqui em breve) pelo mesmo motivo.

Planejamento: como as coisas vão funcionar

Antes de abrir o Visual Studio Code (ou o editor que você preferir) e começar a escrever um monte de coisa, é importante parar um pouco e planejar como o seu robô vai se comportar. Pense bem: como desenvolver um robô que nem você sabe como funciona? Isto dito, vamos começar nosso planejamento definindo bem o que nosso robô vai fazer.

O que o robô vai fazer?

Eu decidi que queria um robô capaz de publicar, todos os dias, às 10h da manhã, um tweet contendo algumas informações sobre uma molécula, sua estrutura química e um link para saber mais. Como um robô faria isso? O primeiro passo para responder essa pergunta é com outra pergunta: como eu faria isso?

O que eu faria?

Bom... Como químico da área de fármacos, eu simplesmente abriria a Wikipédia, procuraria alguma dessas listas e escolheria uma molécula aleatoriamente que eu ainda não tivesse escolhido (para facilitar, manteria uma lista das moléculas que já publiquei, pra não ter que percorrer todo meu Twitter). Daí eu faria um resumo daquele texto na Wikipédia para caber num Tweet, adicionaria um link, a própria estrutura presente na Wikipédia e pronto. Se a Wikipédia não tivesse uma estrutura disponível, eu pesquisaria rapidamente o nome do fármaco no Google Images e pegaria a estrutura. Caso o resultado não fosse satisfatório, como bom Químico Computacional, eu procuraria pelo código SMILES para gerar eu mesmo uma estrutura usando o ChemSketch ou outro software. Feito.

O que um robô deveria fazer?

Ótimo. Podemos elencar esse meu algoritmo. Nosso robô precisa:

• Escolher aleatoriamente uma molécula em alguma lista da Wikipédia que ainda não tenha sido escolhida
• Salvar isso em uma nova lista das moléculas que já foram escolhidas
• Extrair o texto da página escolhida
• Resumir o texto de maneira inteligente (!!!!) para que caiba num Tweet
• Obter a estrutura química, se disponível.
  • Caso indisponível, procurar pelo SMILES para desenhar a estrutura, (computacionalmente, é mais fácil desenhar uma estrutura química que encontrar um bom resultado no Google, já que não temos o recurso bater-o-olho-e-escolher-a-melhor-opção)
  • Caso também indisponível, pesquisar no Google Images.
• Publicar tudo isso no Twitter.

A parte de repetir isso todos os dias será uma tarefa cron no servidor, não é exatamente responsabilidade do nosso robô.

Mas você pode estar se perguntando agora. Pera lá... Resumir texto? Pesquisar no Google? Publicar no Twitter? Como raios um robô vai fazer isso? Bom, vamos lá.

Como o robô vai fazer o que o robô tem que fazer?

Agora sabemos bem o que o robô precisa fazer. Tá na hora de partir para o como. Ainda estamos no planejamento. Sem códigos. Sem fonte monospaced (uma vezinha só, vai). Mas aqui a coisa começa a ficar interessante. Se sentir que está muito rápido, é porque é pra ser assim. Só vamos ver como implementar isso bem mais tarde. Relaxe e prepare-se para uma chuva de links!

1. Escolher moléculas Baseado na lista da Wikipédia que elenquei acima, eu fiz um script para extrair os nomes das moléculas que nosso robô poderá trabalhar. O resultado foi este JSON com mais de 5000 moléculas (não me lembro o número exato agora). Basta escolher uma molécula aleatória nesse JSON e procurá-la na Wikipédia.

2. Obtendo dados da Wikipédia A Wikimedia Foundation (organização que desenvolve a Wikipédia) disponibiliza a API Media Wiki que, dentre outras coisas, permite navegar na Wikipédia de maneira programática (de dentro de um programa). Caso não tivéssemos acesso a uma API, poderíamos usar web scraping (e aqui vai um link da Wikipédia bem no momento que falamos nela kkkkk).

3. Resumir o Texto Hmmm, vou manter o suspense por agora.

4. Obter a estrutura química Vamos dar uma rápida analisada em como a Wikipédia funciona. Acompanhe comigo a página sobre o Paracetamol, droga muito conhecida no Brasil no tratamento sintomático de dores de cabeça e febre. Observe que, à direita, há uma caixa de informações químicas sobre o fármaco. Muitas páginas da Wikipédia e todos (ao menos quase todos) os fármacos contêm essa caixa. Ela é chamada, de maneira geral, de Infobox. Para o nosso caso, duas Infoboxes são esperadas: a Chembox (compostos químicos em geral) e a Drugbox (específica para fármacos). Essas Infoboxes trazem, normalmente, um parâmetro do tipo image* contendo a imagem principal. Voltaremos a isso mais tarde.

5. Obter a estrutura química, Pt. 2: pesquisar no Google Eu sei, pode parecer trivial. Ou impossível. A verdade é que não é nenhum dos dois. O Google nos permite criar um motor de busca personalizado (Custom Search Engine) e fornece gratuitamente uma Custom Search API para fazermos nossas pesquisas. Voltaremos a isso em detalhes mais tarde.

6. Publicar no Twitter Adivinhem. O Twitter também nos fornece uma API através da qual podemos publicar em uma conta. Entretanto, é necessário se aplicar para uma conta de desenvolvedor antes de colocar as mãos na sua Chave de API. Faça isso aqui. Aqui vai a primeira coisa que eu não gostaria de escrever: eu sugiro enfaticamente que você leia atentamente (sério!) todos os termos relacionados à utilização do Twitter como desenvolvedor. Existem diversos limites (muito mais rígidos para robôs que para humanos) que, caso transgredidos, podem (e, acredite, vão) resultar no bloqueio da sua conta. Se usar de maneira responsável, nada de ruim vai acontecer. Enquanto sua aplicação é analisada, comprometa-se a ler a documentação da API do Twitter. Outros desenvolvedores podem discordar, mas, particularmente, achei terrível de ler. Isso não significa que todas as informações não estejam lá. É só que tem informação demais. Procure. Leia. Copiar o meu código não vai te ensinar tanto quanto eu aprendi lendo a API e fazendo funcionar.

7. Resumir o Texto Para resumir o texto, na verdade não vamos implementar nenhum algoritmo de NLP (Processamento de Linguagem Natural). Você pode fazer isso, mas eu vou usar um que já foi implementado (quem sabe em breve eu não implemente o meu rsrsrs). Essa API será fornecida por nós pelo Algorithmia. O Algorithmia não é exatamente gratuito, mas fornece uma quantidade mensal de créditos gratuitos que será mais que o suficiente para nossa aplicação. Acesse o site, clique em Try It For Free e crie sua conta. Dentro do Dashboard, à esquerda, clique em Algorithms e mergulhe na enorme lista de algoritmos disponíveis. Atente-se que cada um consome uma quantidade diferente de créditos todos consomem, no mínimo, um crédito por chamada. Além disso, cada algoritmo pode definir sua cobrança. Você pode testá-los dentro da interface. Este aqui foi o que se saiu melhor (e só consome 1 crédito por requisição). O próprio Algorithmia também fornece outros algoritmos, como o do Google Translate, que você pode implementar se quiser (mais tarde vamos falar sobre isso também). Clique no ícone de perfil e em Manage API Keys e garanta já a sua.

Ok... Temos um planejamento. Vamos à parte mais bonita de todas... Mentira. Mais um passo antes.

Configurando o Ambiente

Bom... Vamos usar Node.js, então precisamos dele instalado. Instale para seu sistema operacional favorito, obviamente o Linux (brincadeira, pode usar o que você quiser). Instale a versão LTS ou, caso goste de viver perigosamente, a versão Current. Se estiver usando Linux, recomendo dar uma olhada nas opções de instalação via package manager. Usaremos diversas dependências, mas, a menos que você esteja copiando um tutorial (o que, obviamente, você não está fazendo), ninguém instala todas as dependências antes de começar a escrever o código.

Isso só pode significar uma coisa...

Coding time

Quem diria! A primeira coisa que precisamos fazer é escolher uma molécula. Como já disse, estou usando este JSON. A estratégia aqui será simples como gerar um número aleatório para escolher uma posição do array e salvar isso nas moléculas já postadas (um JSON análogo). Vamo lá então.

Escolhendo uma molécula

Começaremos criando o ponto de entrada da nossa aplicação (index.js) e também o diretório src/, onde vamos armazenar a maior parte do código. Num primeiro momento, criaremos um arquivo chooseMolecule.js dentro de src/. O código desse arquivo é o que segue.

const { molecules } = require('../all_molecules.json');
const { posted_array } = require('../posted_molecules.json');

const chooseMolecule = () => {
    let moleculeOfTheDay;
    do {
        const rand = Math.floor(Math.random() * molecules.length);
        moleculeOfTheDay = molecules[rand];
    } 
    while (posted_array.indexOf(moleculeOfTheDay) > -1);
    return moleculeOfTheDay;
}

const savePostedMolecule = (posted) => {
    posted_array.push(posted);
    // Salvar o JSON em seguida.
}

// Exportamos tudo
exports.chooseMolecule = chooseMolecule;
exports.saveServer = savePostedMolecule;

Vamos, no index.js, fazer alguma coisa também.

const  { chooseMolecule, savePostedMolecule }  =  require('./src/chooseMolecule');

class Main {
    constructor(){}

    async start(){
        const molecule = chooseMolecule();
        await savePostedMolecule(molecule);
    }
}

// O que estamos fazendo aqui é criar uma função anônima assíncrona e invocando a mesma, permitindo assim o uso do await que, no Node.js, só é permitido em funções assíncronas (diferente do Deno).
(async () => {
    const mainInstance = new Main();
    await mainInstance.start();
})();

Obtendo informações da Wikipédia

---

Cálculo

Primeiramente, vamos analisar a definição precisa de integral através do método do ponto médio. A integral se propõe, no caso $\mathbb{R}^2$, a calcular a área exata sob o gráfico de uma função (ou o volume no caso $\mathbb{R}^3$) no intervalo $[a,b]$. Para isso, podemos dividir o eixo $x$ em $n$ subintervalos. Para cada subintervalo, escolhemos um $x_i^$ e definimos a área desse subintervalo como $f(x_i^)\cdot \Delta x$, em que $\Delta x$ é o tamanho do subintervalo (dado por ${(b-a)/n}$).

A Figura 1 abaixo mostra as diversas somas com $n=4$, $n=8$, $n=16$ e $n= 32$. Observe que, quando $n$ aumenta, a soma das áreas de cada subintervalo se aproxima da área sob o gráfico da função.

Figura 1: Somas convergindo.

Isso pode ser representado, matematicamente, por:

$$A \approx \sum\limits_{i=1}^n {f(x_i^*)\cdot \Delta x}$$

Sendo assim, se tomamos o limite quando $ n \to \infty $, então obtemos uma soma perfeita:

$$\int\limits_a^b{f(x)dx} = \lim_{n \to \infty} {\sum\limits_{i=1}^n {f(x_i^*)\cdot \Delta x}}$$

Infelizmente, são muitos os casos em que é simplesmente impossível calcular o limite infinito para encontrar uma integral exata. Daí recorremos a métodos de aproximação. Apenas remover o limite e escolher um $n$ arbitrariamente grande é chamado de Método dos Retângulos. Um outro método, com um erro bem menor, é o Método dos Trapézios, ou Integração Trapezoidal.

Nesse método, em vez de somar vários retângulos, cada um aproximando a área entre $x_{i-1}$ e $x_i$, usamos trapézios. Veja na Figura abaixo a comparação entre os dois métodos.

Figura 2(a): Integração por Retângulos.

Figura 2(b): Integração Trapezoidal.

A implementação desse método é parecida com o dos retângulos. Começamos dividindo o intervalo de integração $[a,b]$ em $n$ subintervalos de tal forma que $\Delta x = \frac{b-a}{n}$.

A área do trapézio é dada por: $$\frac{(B+b)\cdot h}{2}$$ Em que $B$ e $b$ são as bases do trapézio e $h$ é a altura. No nosso caso (considere o $i$-ésimo subintervalo), a "altura" do trapézio é $\Delta x$, ao passo que as bases são $f(x_i)$ e $f(x_{i-1})$.

Observação: note que $x_0 = a$ e $x_n = b$ .

Podemos, então, tomar um $n$ arbitrariamente grande e teremos a integral aproximada:

$$\int\limits_a^b {f(x)dx} \, \approx \, \sum\limits_{i=1}^n {\frac{[f(x_i) + f(x_{i-1})]\cdot \Delta x}{2}}$$

Como ${\Delta x}/{2}$ é uma constante, pode ser removido da soma.

$$\int\limits_a^b {f(x)dx} \, \approx \, \frac{\Delta x}{2}\sum\limits_{i=1}^n {[f(x_i) + f(x_{i-1})]}$$

Então temos a equação final para o método dos trapézios. Basta, agora, implementá-lo.

Veja a implementação:

• Portugol Studio

• Python

Observe que este conteúdo utiliza javascript puro e certamente podem haver maneiras mais eficientes de fazer isto a depender do seu caso de uso em particular. Caso seja necessário, entre em contato para auxílio profissional.

O Efeito de Alternância (Toggle)

A ideia é ter um botão que, ao ser clicado, mostra ou oculta um bloco de conteúdo. Podemos conseguir isso com uma única e simples função JavaScript.

O Código JavaScript

Em vez de usar duas funções (mostrar e fechar), podemos usar apenas uma função toggleVisibility que verifica o estado atual do elemento e o inverte. Isso torna o código mais limpo e eficiente.

function toggleVisibility(id) {
  const element = document.getElementById(id);
  if (!element.style.display || element.style.display === 'none') {
    element.style.display = 'block';
  } else {
    element.style.display = 'none';
  }
}

Estrutura HTML

A estrutura HTML é direta. Você precisa de um elemento clicável (como um botão ou link) que chame a função e um div com um id único que contenha o conteúdo a ser ocultado.

<a onclick="toggleVisibility('ID_DO_SEU_CONTEUDO')">Clique para Mostrar/Ocultar</a>

<div id="ID_DO_SEU_CONTEUDO" style="display: none;">
  <p>Aqui vai o seu conteúdo...</p>
</div>

Vídeo Explicativo

O vídeo original que demonstrava o efeito pode ser acessado aqui: