lurodrigo’s blog

Sobre uma pequena conexão entre anagramas e números primos

2018-04-26T10:00:00-03:00

Esses dias estava circulando no twitter o seguinte algoritmo para verificar se duas palavras são anagramas:

Clever algorithm to find out whether or not 2 words are anagrams pic.twitter.com/rRNqnq6wG9
— Fermat's Library (@fermatslibrary) 23 de abril de 2018

Tradução livre: Algoritmo esperto para descobrir se duas palavras são ou não anagramas.

Relacione cada uma das 26 letras A, B, C, D\dots a um número primo. Multiplique os primos correspondentes às letras de cada palavra. Como todo inteiro é um primo ou um produto único de primos (pelo Teorema Fundamental da Aritmética), duas palavras são anagramas se os resultados forem iguais. Exemplo:

\[f(A) = 2, f(E) = 5, f(R) = 7\] \[f(ARE) = 2 \times 7 \times 5 = 70\] \[f(EAR) = 5 \times 2 \times 7 = 70\]

Do ponto de vista técnico, há problemas^[1] a serem considerados para uma implementação computacional efetiva desse algoritmo, mas é possível identificar uma estrutura matemática até rica e profunda nele. Ao mesmo tempo, é suficientemente simples para ser entendido por não-matemáticos. A ideia do post é identificar quais as estruturas algébricas envolvidas nessa ligação entre anagramas e aritmética.

Um pouquinho de terminologia da álgebra

Matemáticos podem pular essa seção.

Uma estrutura algébrica é um conjunto que tem algumas operações definidas sobre ele. Uma estrutura álgebra que todos conhecem é o conjunto, a estrutura que obtemos quando não definimos nenhuma operação. :)

Falemos de estruturas algébricas mais interessantes. Um monoide é um conjunto com uma operação binária $\cdot$ satisfazendo duas condições:

Associatividade: Dados três elementos $a, b, c$ do conjunto, vale $(a \cdot b) \cdot c = a \cdot (b \cdot c)$. Essencialmente, isso quer dizer que, dada uma sequência de operações a serem realizadas, não trocando a ordem dos elementos, tanto faz se começo a fazer as contas pela esquerda ou pela direita.
Elemento neutro: Existe um elemento $e$ de modo que, qualquer que seja o elemento $a$ do conjunto, vale $a \cdot e = e \cdot a = a$. Ou seja, fazer a conta quando um dos operandos é $e$ não muda o resultado.

Sejamos mais concretos.

Exemplo 1: Um exemplo de monoide é $(\mathbb{N} \cup \{0\}, +)$, isto é, o conjunto dos inteiros não-negativos com a operação soma. Considere a soma $2 + 3 + 5$, por exemplo. Essa soma poderia ser feita de dois modos: $(2 + 3) + 5 = 5 + 5 = 10$ ou $2 + (3 + 5) = 2 + 8 = 10$. Nos dois casos, tivemos o mesmo resultado. Como isso acontece quaisquer que sejam os números escolhidos, podemos dizer que a soma é associativa. O elemento neutro da soma é o número $0$, que não faz nenhuma diferença ao ser somado com algum outro número.

$(\mathbb{N}, \times)$ (sem o zero!) também é um monoide. Por exemplo, $(2 \times 3) \times 5 = 6 \times 5 = 30 = 2 \times 15 = 2 \times (3 \times 5)$, e isso acontece independentemente da escolha dos números. O elemento neutro da multiplicação é o número $1$, que não faz nenhuma diferença quando multiplicado com algum outro número.

Exemplo 2: Em computação, uma string é uma sequência de caracteres de algum alfabeto finito. Exemplos são “Tamarindo”, “isso não é uma string” e “” (a string vazia). Uma operação natural envolvendo strings é a concatenação (que aqui chamo de ++), que consiste em adicionar os caracteres de uma string ao final da outra: “monoides” ++ “e” ++ “tal” = “monoidesetal”. O conjunto das strings, junto com a operação de concatenação, forma um monoide, onde o elemento neutro é a string vazia.

Exemplo 3: Um exemplo um pouco semelhante é dado pelas tabelas. Tabelas com colunas compatíveis podem ser concatenadas, gerando uma tabela com os dados das duas. A tabela com 0 linhas é o elemento neutro desse monoide.

Exemplo 4: Os exemplos 2 e 3 foram construídos da mesma maneira. São exemplos de monoides livres, aqueles construídos como o conjunto de sequências sobre um determinado alfabeto, com a operação de concatenação. Em um caso o alfabeto é de fato constituído por caracteres, no outro, os “caracteres” são os valores possíveis que uma linha pode assumir.

Exemplo 5: Pensemos em somente dois valores: par ou ímpar. Definimos uma operação soma sobre esses dois valores de forma intuitiva: par + par = ímpar + ímpar = par e par + ímpar = ímpar + par = ímpar. O conjunto {par, impar} com essa soma é um monoide, onde o elemento neutro é par.

Podemos pensar monoides como uma estrutura em que elementos podem ser “combinados” ou “acumulados” de certa forma. Acontece que, abstraindo um pouco as particularidades dos objetos e das operações, percebemos que alguns monoides se comportam da mesma maneira que outros.

Pense no conjunto $\{1, 2, 4, 8, 16, \dots\}$ isto é, as potências inteiras e positivas de 2. Se multiplicamos duas potências de base 2, conseguimos uma terceira potência de base 2. $4 = 2 \times 2$, $8 = 2 \times 2 \times 2$, e multiplicando 4 por 8 temos 32, que é $2 \times 2 \times 2 \times 2 \times 2$. Quando multiplicamos duas potências de base dois, o que estamos fazendo é essencialmente contar quantos 2 multiplicados aparecem nos dois números, e somamos. Em 4, temos o número 2 repetido duas vezes; em 8, repetido três vezes; logo, o resultado é o número onde 2 aparece cinco vezes, 32. Num certo sentido, multiplicar potências de uma mesma base é a mesma coisa que somar.

Essa intuição pode ser formalizada. Dizemos que o monoide do exemplo 1 (os naturais e zero com a soma) e o monoide que acabei de criar são isomórficos. Um isomorfismo (de monoides) é uma correspondência 1-pra-1 (em matematiquês, uma função bijetiva) entre os elementos dos monoides que mantém as operações funcionando. Isso quer dizer que eu posso trabalhar com um monoide ou com o outro conforme a conveniência, porque do ponto de vista das operações, esses dois monoides são apenas representações diferentes da mesma coisa.

No caso anterior, o isomorfismo é dado pela função $f: n \mapsto 2^n$. $f$ leva 0 em 1, 1 em 2, 2 em 4, 3 em 8, 4 em 16 e assim vai. Essa função é inversível: podemos voltar atrás com a função $f^{-1}: n \mapsto \log_2 n$. Com 8, temos $\log_2 8 = 3$; com 16, $\log_2 16 = 4$; enfim, podemos transitar livremente entre um conjunto e outro usando $f$ e $f^{-1}$.

Observação: se temos uma correspondência 1-para-1 entre $\{0, 1, 2, 3, 4, \dots\}$ e $\{1, 2, 4, 8, \dots\}$, significa que os dois conjuntos têm a mesma quantidade de elementos, ainda que o segundo seja apenas uma parte do primeiro. Conjuntos infinitos são complicados.

Eu havia dito que um isomorfismo mantém as operações funcionando. Matematicamente, se temos dois monoides $(A, \cdot_A)$ e $(B, \cdot_B)$, um isomorfismo $f$ satisfaz a condição $f(a \cdot_A b) = f(a) \cdot_B f(b)$. Pensemos no caso concreto em que estamos trabalhando. Os monoides são $(\mathbb{N} \cup \{0\}, +)$ e $(\{1, 2, 4, 8, \dots\}, \times)$. Temos $f(2) = 4$, $f(3) = 8$ e $f(2 + 3) = f(5) = 32$. Observamos que $f(2 + 3) = f(2) \times f(3)$! Podemos somar os números primeiro e depois transformar, podemos transformar os números primeiro e depois multiplicar: tudo vai dar no mesmo.

Pensando na outra direção, acabamos de inventar um jeito de fazer multiplicações fazendo apenas somas. Para multiplicar dois números, olhamos qual potência de base 2 corresponde a esses números. Somamos os expoentes dessas potências, e calculamos a potência com esse novo expoente. Isso é exatamente o que os logaritmos fazem. logaritmos são isomorfismos entre grupos (uma especialização dos monoides), que transformam multiplicações em adições. Isso teve uma grande importância histórica, pois na falta de computadores é mais fácil e seguro fazer somas que multiplicações. Na verdade, até com computadores isso às vezes acontece.

Para multiplicar dois números grandes, olhamos o logaritmo deles (na tabela de logaritmos), somamos esses números e olhamos na tabela qual número tem o logaritmo igual a essa soma. O número encontrado é a multiplicação dos dois anteriores.

De modo geral, o papel dos isomorfismos é tirar toda a bagunça que está sobre um objeto complicado e mostrar que, no fundo, aquele objeto é mais simples do que parecia inicialmente.

E o que isso tem a ver com anagramas?

Como podemos descobrir se duas strings são anagramas uma da outra? Bem, um modo de fazer isso é colocando as duas em ordem alfabética. “are” e “ear”, quando postas em ordem alfabética, viram ambas “aer”, logo, são anagramas. E como podemos ordenar strings? O modo mais eficiente (computacionalmente) para isso é contar quantas vezes cada caractere aparece e, a partir disso, construir uma nova string. Esse algoritmo se chama Counting Sort e é o método de ordenação mais eficiente que há para certos tipos de dados.

Um exemplo do seu uso: em “amar” temos ‘a’ repetido 2 vezes e ‘m’ e ‘r’ aparecendo uma vez cada. Portanto, a ordenação de “amar” é “aarm”. Como “arma” quando ordenada também vira “aarm”, concluímos que “arma” e “amar” são anagramas.

Observamos uma coisa: não precisamos de fato ordenar as palavras para verificar se são anagramas. A ordem das letras dentro da palavra não importa, só precisamos saber quantas vezes cada letra aparece. Se a contagem bater, são anagramas.

Um isomorfismo preserva informação. Já a contagem de aparições de letras em palavras, que chamarei de $[\cdot]$, descarta informação. É possível ir de “amar” ao multiconjunto [“amar”] = {‘a’: 2, ‘m’: 1, ‘r’: 1}, mas de {‘a’: 2, ‘m’: 1, ‘r’: 1} não há como distinguir entre “amar” ou “arma”. Essa transformação não é um isomorfismo.

A operação correspondente à concatenação é a soma de multiconjuntos. Por exemplo, a soma de dois multiconjuntos onde ‘a’ aparece duas vezes e ‘m’ e ‘r’ aparecem uma vez é um multiconjunto onde ‘a’ aparece quatro vezes e ‘m’ e ‘r’ aparecem duas vezes. A transformação preserva a estrutura da operação: [“arma” ++ “amar”] = [“armaamar”] = {‘a’: 4, ‘m’: 2, ‘r’: 2} e [“arma”] ++ [“amar”] = {‘a’: 2, ‘m’: 1, ‘r’: 1} + {‘a’: 2, ‘m’: 1, ‘r’: 1} = {‘a’: 4, ‘m’: 2, ‘r’: 2}. Podemos concatenar duas strings e contar as letras ou contar as letras e somar os multiconjuntos, dá no mesmo.

Observação: os matemáticos e leitores do meu texto sobre partições talvez notem que a contagem de letras cria partições no conjunto de strings. De fato, “ser anagrama de” é uma relação de equivalência: se A é anagrama de B e B é anagrama de C, A é anagrama de C. As condições de reflexividade e simetria são facilmente verificadas. Os multiconjuntos que obtemos aplicando $[\cdot]$ às strings têm uma correspondência natural com (são isomórficos a) as classes de equivalência, formadas pelas strings que são anagramas entre si.

Quando apenas a estrutura é garantidamente preservada, temos um homomorfismo. Homomorfismos são a regra geral; isomorfismos são um caso particular: nem sempre é possível ou desejável preservar informação. Um outro exemplo de homomorfismo que não preserva informação é dado pela função que leva um inteiro $n$ em par ou impar, se $n$ for par ou ímpar, respectivamente (ver exemplo 5). Com isso, provamos que, para verificar se a soma de vários números inteiros é par ou ímpar, não precisamos nem conhecer quais números estamos somando, só precisamos saber quantos ímpares e quantos pares temos. Afinal, se é homomorfismo, tanto faz se primeiro somamos e depois verificamos paridade ou se primeiro verificamos paridade e depois somamos!

Voltando. Na verdade, com o homomorfismo que construímos, não apenas preservamos como ganhamos estrutura: a soma de multiconjuntos é comutativa, enquanto a concatenação de strings não é. Podemos somar dois multiconjuntos em qualquer ordem e teremos o mesmo resultado, mas a concatenação de strings depende da ordem dos operandos. “abc” ++ “def” = “abcdef”, enquanto “def” ++ “abc” = “defabc”. A comutatividade de uma operação costuma ser desejável porque garante que podemos utilizar vários resultados previstos para operações comutativas. Todos os resultados que conhecemos para monoides valem para monoides comutativos, mas existem teoremas que valem exclusivamente para monoides comutativos. De certa forma, fizemos uma troca: perdemos informação para ganhar estrutura. E, nesse caso, a comutativade é fundamental: é justamente ela que garante que o resultado da contagem dará o mesmo independente da ordem das letras, oras!

Por último, notamos que há um isomorfismo entre multiconjuntos e (uma parte dos^[2]) números inteiros. Para um alfabeto com três letras, temos multiconjuntos com três letras (e suas repetições). Podemos associar a primeira letra ao número 2, a segunda ao número 3 e a terceira ao 5. Se tivermos mais letras, é só continuar na sequência de primos.

O fato dessa ligação entre letras e primos ser um isomorfismo garante que contar mais uma letra é a mesma coisa que multiplicar pelo primo correspondente. Aplicando isso à string toda, descobrimos que contar todas as letras é matematicamente a mesma coisa que multiplicar números primos, são apenas representações diferentes da mesma operação.

Para fechar, um último comentário: se a associação fosse apenas um homomorfismo, não teríamos falsos negativos. Se duas palavras têm as mesmas letras, elas iriam para os mesmos números, que multiplicados dariam o mesmo resultado. O problema é com falsos positivos: poderia ser que, dependendo da forma como a associação entre letras e números fosse feita, palavras formadas por letras diferentes levassem ao mesmo resultado de multiplicação. Um exemplo é ‘a’ $\mapsto$ 2, ‘b’ $\mapsto$ 18, ‘c’ $\mapsto$ 3, ‘d’ $\mapsto$ 12. “ab” vai em $2 \times 18 = 36$, o mesmo resultado de “cd”, que vai em $3 \times 12 = 36$. Isso não acontece com primos, pois o Teorema Fundamental da Aritmética garante que existe um único jeito de formar um número como multiplicação de primos. Isso garante o isomorfismo: como essa decomposição é única, basta contar quantas vezes cada primo aparece para reconstruir a contagem original das letras.

Mas tanta linguagem nova pra quê?

O leitor crítico pode se perguntar por que fazer uma análise tão minuciosa, repleta de terminologia técnica, de um algoritmo relativamente trivial. A resposta imediata é que isso tudo é muito divertido e bonito. A resposta séria é que, quando abstraímos as particularidades dos objetos que estamos trabalhando e pensamos só na forma como os objetos se relacionam uns com os outros, podemos aplicar as mesmas técnicas para objetos que se comportam da mesma forma, ainda que venham de contextos completamente diferentes!

De fato, eu comentei no exemplo 4 que as strings são apenas um caso particular de uma construção mais geral: sequências finitas sobre um alfabeto. Isso implica que o algoritmo que estudamos pode ser aplicado, em princípio, para verificar “anagramas” em qualquer tipo de sequência. Poderíamos, por exemplo, verificar se dois textos diferentes são compostos exatamente das mesmas palavras, usando a mesma técnica.

Para que o algoritmo funcione, tanto faz a natureza dos objetos: sequências de caracteres, tabelas, imagens, whatever! O que importa são as propriedades desses objetos quando combinados. Não a toa essas ideias, importadas da álgebra abstrata, são aplicadas em programação funcional: podemos escrever um mesmo código para trabalhar com infinitos tipos de objetos, desde que tenham uma certa estrutura em comum.

[1]: O principal problema técnico desse algoritmo é que o resultado da multiplicação de vários primos vai crescendo rapidamente à medida que a quantidade de letras aumenta, e os computadores tipicamente só conseguem armazenar de forma eficiente números inteiros de até um certo tamanho. Acima disso, o algoritmo vai se comportar de forma muito pouco eficiente. Talvez com outro modelo de computação essa implementação seja mais viável.

[2]: Tecnicamente, o isomorfismo é entre os multiconjuntos com $n$ letras e o conjunto dos inteiros que não têm outros fatores primos que não os $n$ primeiros primos.

Uma introdução ao Shiny e reatividade

2018-03-05T10:00:00-03:00

Esse post é bem antigo. Muita coisa pode estar incorreta devido a novidades que aconteceram desde então, ou porque meu entendimento na época não era tão claro.

O Shiny é um framework web para criação de aplicativos interativos. Diferente dos frameworks para desenvolvimento web usuais, não há, necessariamente, necessidade de conhecer HTML, CSS ou Javascript, as linguagens básicas usadas para construir páginas da web.

A estrutura de um aplicativo Shiny

Um aplicativo Shiny consiste de pelo menos dois arquivos: ui.R e server.R. O arquivo ui.R descreve a interface do aplicativo e o server.R, a lógica. Na verdade, é possível construir aplicativos em um único arquivo app.R, mas é um approach inadequado para qualquer aplicativo com alguma complexidade, então não comentarei sobre. Opcionalmente, é possível definir um arquivo global.R. Tudo que for definido no arquivo global.R estará acessível tanto em ambos ui.R e server.R. Portanto, recomendo usar o arquivo global para carregar os pacotes e definir funções, variáveis e constantes úteis para o aplicativo.

# global.R

library(shiny)
library(shinydashboard)

O arquivo ui.R especifica a estrutura da página através de uma domain- specific language. Essencialmente, o Shiny provê um conjunto de funções R que, nestadase combinadas de maneira adequada, geram o código HTML correspondente. Eu gosto de usar o pacote shinydashboard, que permite a criação de dashboards com estrutura um pouco mais complexa e melhor aparência em comparação aos aplicativos Shiny padrão sem ter que se preocupar muito com as configurações. A página mais simples possível a ser gerada com o Shiny Dashboard é a seguinte:

# ui.R

dashboardPage(
  dashboardHeader(),
  dashboardSidebar(),
  dashboardBody()
)

Note que isso só gera HTML:

print(dashboardPage(
  dashboardHeader(),
  dashboardSidebar(),
  dashboardBody()
))
#> <body class="skin-blue" style="min-height: 611px;">
#>   <div class="wrapper">
#>     <header class="main-header">
#>       <span class="logo"></span>
#>       <nav class="navbar navbar-static-top" role="navigation">
#>         <span style="display:none;">
#>           <i class="fa fa-bars"></i>
#>         </span>
#>         <a href="#" class="sidebar-toggle" data-toggle="offcanvas" role="button">
#>           <span class="sr-only">Toggle navigation</span>
#>         </a>
#>         <div class="navbar-custom-menu">
#>           <ul class="nav navbar-nav"></ul>
#>         </div>
#>       </nav>
#>     </header>
#>     <aside class="main-sidebar" data-collapsed="false">
#>       <section class="sidebar"></section>
#>     </aside>
#>     <div class="content-wrapper">
#>       <section class="content"></section>
#>     </div>
#>   </div>
#> </body>

O arquivo server.R deve se encerrar em uma função com três parâmetros: input, output e session, sendo o último opcional. Logo, o arquivo server.R mais simples é o seguinte:

# server.R

function(input, output, session) {
  
}

Tendo esses três arquivos, já é possível gerar nosso primeiro aplicativo Shiny. No RStudio, clique no botão “Run App” que está onde o botão “Source” costumava estar.

Estrutura da UI

Podemos, é claro, customizar a interface. Podemos passar para a função dashboardHeader(), entre outras coisas, o parâmetro title. Também é possível criar menus dropdown.

dashboardHeader(title = "Appzinho")

As abas são criadas utilizando a função sidebarMenu() e passadas como parâmetro para o dashboardSidebar(). Para a função sidebarMenu() devem ser passados items criados com a função menuItem(). O primeiro item é o nome da aba como ela deve aparecer na sidebar. O parâmetro tabName é o mais importante: deve ser id único para identificar aquela aba. O parâmetro icon, opcional, associa à aba um ícone. Os identificadores que a função icon aceita podem ser encontrados neste link.

dashboardSidebar(
  sidebarMenu(
    menuItem("Aba 1", tabName = "aba1", icon = icon("star")),
    menuItem("Aba 2", tabName = "aba2", icon = icon("tag"))
  )
)

De modo similar, o conteúdo é especificado na função tabItems(), que deve ser passada como parâmetro para dashboardBody(). O conteúdo de cada aba é criado dentro da função tabItem(). Seu parâmetro mais importante é o tabName, que liga o link de uma aba na sidebar ao seu conteúdo. Obviamente, o valor de tabName deve corresponder ao de algum menuItem() da sidebar.

dashboardBody(
  tabItems(
    tabItem(tabName = "aba1", 
      "Conteúdo da primeira aba"
    ),
    tabItem(tabName = "aba2", 
      "Conteúdo da segunda aba"
    )
  )
)

Com todas essas modificações no arquivo ui.R:

# ui.R

dashboardPage(
  dashboardHeader(title = "Appzinho"),
  dashboardSidebar(
    sidebarMenu(
      menuItem("Aba 1", tabName = "aba1", icon = icon("star")),
      menuItem("Aba 2", tabName = "aba2", icon = icon("tag"))
    )
  ),
  dashboardBody(
    tabItems(
      tabItem(tabName = "aba1", 
        "Conteúdo da primeira aba"
      ),
      tabItem(tabName = "aba2", 
        "Conteúdo da segunda aba"
      )
    )
  )
)

O conteúdo se organiza dentro de caixinhas (boxes) que podem ser de quatro tipos diferentes: box(), tabBox(), infoBox(), valueBox(). A forma como eles se distribuem pela página pode ser por colunas, por linhas, ou um misto dos dois. A página do shinydashboard explica melhor essas possibilidades. Por enquanto, vou apenas criar duas caixinhas vazias para, nas próximas seções, criar alguma funcionalidade.

dashboardBody(
    tabItems(
      tabItem(tabName = "aba1", 
        fluidRow(
          box(title = "Opções"),
          box(title = "Resultado", status = "primary")
        )
      ),
      tabItem(tabName = "aba2", 
        "Conteúdo da segunda aba"
      )
    )
  )

Eventos vs Reatividade

A lógica pela qual as interações usuário-sistema ocorrem no Shiny é um pouco diferente do que ocorre em outros frameworks. A grande maioria deles utiliza uma lógica baseada em eventos. Isto inclui VBA, jQuery, .NET… Esses frameworks functionam, essencialmente, a partir da definição de handlers para eventos que te interessam. Por exemplo, imagine que uma interface tem uma caixinha “Sim/Não” cujo valor interferisse na interface. Você teria que escrever código que transformasse a interface do estado “sim” para o estado “não” e vice-versa.

O principal problema do approach de eventos é que você tem que se preocupar com o estado atual da aplicação e definir como chegar no próximo estado. Usando uma analogia péssima, é como se precisássemos programar como chegar ao estado s_n + 1 em função do estado s_n.

Já o Shiny usa um approach chamado reatividade. A ideia é evitar que nos preocupemos com o estado da aplicação: descrevemos como s_n depende de n somente. O estado do aplicativo é definido como uma função de determinadas variáveis. Isto é, você definir como a interface deve estar quando as variáveis assumirem seus valores. Toda vez que os valores forem atualizados, o Shiny reage e atualiza automaticamente os elementos da interface que dependem dele.

Vários frameworks novos, como o Angular (da Google) e o React (do Facebook) seguem essa ideia, mas ela na verdade é bem antiga. Planilhas do excel são exemplos clássicos de ambientes reativos: você define o valor de uma célula como um cálculo a partir do valor de outras. Toda vez que uma dessas células é atualizada, o valor é recalculado.

Um primeiro exemplo de reatividade

Vamos produzir uma funcionalidade bem simples: o usuário deve os fornecer uma texto e um número, e a saída produzida deve ser o texto dado repetido n vezes. Para isso, precisamos primeiramente definir objetos de entrada e de saída.

Objetos de entrada e saída

Os valores resultantes das interações do usuário com o aplicativo entram através de objetos de input. Eles devem ser definidas no arquivo ui.R através de funções que tipicamente terminam em Input [1]. Precisamos de uma caixa de texto e de uma caixa numérica. O código abaixo faz isso. O parâmetro mais importante é o primeiro: define um id para esses elementos. É através desses ids que conseguiremos recuperar seus valores mais tarde.

textInput("texto", label = "Texto: ")

numericInput("numero", label = "Número: ", value = 0, min = 0)

Precisamos também de um objeto de output para exibir o resultado. Objetos de output também são definidos no ui.R, tipicamente por via de funções terminadas em Output. No caso, queremos uma saída de texto. Nesse caso simples passamos um único parâmetro, o seu id.

textOutput("saida")

Aplicando isso ao ui.R:

tabItem(tabName = "aba1", 
  fluidRow(
    box(title = "Opções", solidHeader = TRUE,
      textInput("texto", label = "Texto: "),
      numericInput("numero", label = "Número: ", value = 0, min = 0)
    ),
    box(title = "Resultado", status = "primary",
      textOutput("saida")
    )
  )
)

Obtemos o seguinte:

Já podemos brincar com os elementos de entrada, mas nada acontece ainda porque precisamos definir o que a aplicação deve fazer.

Definindo o comportamento da aplicação

É nesse pedaço que entra o arquivo server.R. O código que faz a funcionalidade que queremos é bem simples:

rep(texto, numero) %>% paste(collapse = " ")

Basta então aplicar a lógica do Shiny. Os valores de entrada devem ser acessados através da variável input e os de saída, especificados através da variável output. Com um detalhe: esse código deve estar dentro de uma função renderizadora correspondente ao tipo de output. Como temos um textOutput, precisamos enviar esse código para a função renderText() e então atribuir esse valor algum output.

Vejamos como isto fica na prática:

# global.R

library(shiny)
library(shinydashboard)
library(dplyr)

# server.R

function(input, output, session) {
  output$saida = renderText({
    rep(input$texto, input$numero) %>% paste(collapse = " ")
  })
}

Obtemos o seguinte resultado:

Note que, anteriormente, eu havia falado que a ideia da reatividade é definir elementos da interface em função do valor das outras. Neste caso, saida é uma função dos valores de input$texto e input$numero. Note que isso não ocorre de maneira explicita: não definimos nenhuma function com esses dois parâmetros. Os mecanismos internos do Shiny leem o bloco de código que passamos para a função renderizadora e conseguem detectar quais os valores reativos de que esse código depende. Neste caso são apenas dois. Sabendo disso, o Shiny reexecuta o bloco de código toda vez que um dos valores for atualizado.

Um segundo exemplo de reatividade

O próximo exemplo irá mostrar que descrever interações através da reatividade não é uma tarefa tão trivial.

Parando reações: isolate()

Teremos inicialmente um input numérico e um botão. Deve ser gerado um gráfico contendo n pontos aleatórios. Esse botão deve gerar um novo plot aleatório toda vez que for clicado.

Começamos definindo os novos elementos gráficos necessários. Precisaremos de uma caixa numérica, um botão e uma saída de plot. O código seguinte para a segunda aba faz isso:

tabItem(tabName = "aba2", 
  fluidRow(
    box(title = "Parâmetros",
      numericInput("npontos", "Número de pontos:", value = 10, min = 0),
      actionButton("atualizar", "Atualizar")
    ),
    box(title = "Plot",
      plotOutput("plot")
    )
  )        
)

O código corresponde no server seria o seguinte:

output$plot = renderPlot({
  df = data.frame(
    x = rnorm(input$npontos),
    y = rnorm(input$npontos)
  )
  
  ggplot(df, aes(x = x, y = y)) + geom_point() + 
    geom_smooth(method = "lm", se = FALSE)
})

O exemplo anterior, do modo como está, tem um pequeno contratempo: Ele gera um gráfico novo toda vez que o valor de npontos mudar. Ocorre que esse talvez não seja o melhor comportamento, pois quando digitamos um número grande, serão gerados alguns plots intermediários com duração efêmera, o que pode, dependendo do tipo de processamento, causar travamentos ou impacto visual desagradável.

Precisamos então colocar o botão de atualizar para funcionar, mas temos uma questão conceitual para pensar primeiro. Num framework reativo, as expressões reativas são recalculadas toda vez que um dos valores reativos muda. Queremos que o plot seja gerado novamente a cada clique no botão, então é claro que o plot depende, de certa forma, do botão. Mas o que seria o valor do botão? Claramente, um botão não tem armazena nenhum valor intrinsecamente. A solução implementada pelos engenheiros do Shiny é associar ao botão o número de vezes que ele foi clicado. Dessa forma, toda vez que for clicado, a contagem aumenta e as reações são desencadeadas.

Voltando ao nosso código, basta que adicionemos uma referência a input$atualizar em algum momento no interior de renderPlot(). No caso, terá de ser uma referência um tanto vazia:

output$plot = renderPlot({
  input$atualizar
  
  df = data.frame(
    x = rnorm(input$npontos),
    y = rnorm(input$npontos)
  )
  
  ggplot(df, aes(x = x, y = y)) + geom_point() + 
    geom_smooth(method = "lm", se = FALSE) 
})

O botão agora funciona, mas ainda precisamos fazer com que o plot pare de atualizar toda vez que o número de pontos for alterado. Ele certamente depende desse número de pontos, porém. E agora?

Esse é um caso de uso típico da função isolate(): queremos usar um valor ou expressão reativa, mas não queremos criar uma relação de dependência reativa. Basta colocar o valor ou a expressão reativa dentro de isolate():

output$plot = renderPlot({
  input$atualizar
  
  npontos = isolate(input$npontos)
  df = data.frame(
    x = rnorm(npontos),
    y = rnorm(npontos)
  )
  
  ggplot(df, aes(x = x, y = y)) + geom_point() + 
    geom_smooth(method = "lm", se = FALSE) 
})

Condutores reativos: reactive()

No caso em que trabalhamos só com um plot, é aceitável gerar esses dados aleatórios dentro do renderPlot(). Suponha que queiramos gerar dois (ou mais) gráficos diferentes a partir da mesma tabela. Não poderíamos mais simplesmente gerar os tabela dentro de um dos renderizadores, pois ela não seria acessível dentro do outro renderizador. Também não faria sentido colocar o código que gera os pontos em cada renderizador, pois seriam gerados com alta probabilidade plots diferentes.

Precisamos, então, gerar os pontos fora dos renderizadores de algum modo. Tente o seguinte:

# server.R

function(input, output, session) {
  output$saida = renderText({
    rep(input$texto, input$numero) %>% paste(collapse = " ")
  })
  
  npontos = isolate(input$npontos)
  
  df = data.frame(
    x = rnorm(npontos),
    y = rnorm(npontos)
  )
  
  output$plot = renderPlot({
    input$atualizar

    ggplot(df, aes(x = x, y = y)) + geom_point() + 
      geom_smooth(method = "lm", se = FALSE) 
  })
}

Agora o plot não atualiza mais de jeito nenhum! Por quê? Porque df não está definido num contexto reativo, ela está no corpo da função do modo usual. Isso implica que aquele trecho de código só será executado uma vez, logo que o server.R é carregado no início. Note que isso independe do uso de isolate().

Para resolver esse tipo de situação (e outras mais) foi pensado o conceito de condutor reativo, que se aplica ao que queremos fazer com o df. Queremos que ele seja uma função de npontos (e do botão de atualizar) e que, por sua vez, os plots sejam uma função de df. A terminologia surge por analogia: df estará conduzindo reações dos inputs até os outputs.

Ok, como sempre, primeiro temos que definir os plots na ui:

tabItem(tabName = "aba2", 
  fluidRow(
    box(title = "Parâmetros",
      numericInput("npontos", "Número de pontos:", value = 10, min = 0),
      actionButton("atualizar", "Atualizar")
    ),
    box(title = "Plot",
      plotOutput("plot")
    )
  ),
  fluidRow(
    box(title = "Distribuição do x",
      plotOutput("plotx")    
    ),
    box(title = "Distribuição do y",
      plotOutput("ploty")    
    )
  )
)

Para definir condutores reativos, usamos a função reactive() com um valor ou expressão dentro. Um detalhe chato é que, para usar os valores definidos deste modo, precisamos suceder o nome com parênteses, do mesmo modo que chamamos funções.

# server.R

function(input, output, session) {
  output$saida = renderText({
    rep(input$texto, input$numero) %>% paste(collapse = " ")
  })
  
  df = reactive({
    input$atualizar
    npontos = isolate(input$npontos)
    
    data.frame(
      x = rnorm(npontos),
      y = rnorm(npontos)
    )
  })

  output$plot = renderPlot({
    ggplot(df(), aes(x = x, y = y)) + geom_point() + 
      geom_smooth(method = "lm", se = FALSE) 
  })
  
  output$plotx = renderPlot({
    ggplot(df()) + geom_density(mapping = aes(x = x))
  })
  
  output$ploty = renderPlot({
    ggplot(df()) + geom_density(mapping = aes(x = y))
  })
}

Ações event-like: observe() e observeEvent()

Existem casos de uso que simplesmente não se encaixam de uma forma óbvia no paradigma de reatividade. Casos envolvendo botões são os mais clássicos. Imagine que queremos colocar uma caixa de texto para definir o título do plot. É conveniente um botão para apagar a caixa de texto. A ação de apagar o texto claramente acontece como reação ao aperto de botão, mas ela não gera valor nenhum. Nesse caso, usamos observadores. Eles observam toda vez que os valores reativos no código mudam e, quando isso ocorre, o reexecuta, mas nenhum valor precisa ser gerado.

Primeiro, adicionemos os elementos necessários à UI.

box(title = "Parâmetros",
  textInput("titulo", "Título do plot: "),
  numericInput("npontos", "Número de pontos:", value = 10, min = 0),
  actionButton("atualizar", "Atualizar"),
  actionButton("limpar", "Limpar")
)

Para implementar observadores, podemos usar equivalentemente observe() ou observeEvent(). A diferença entre as duas é que observeEvent() observa apenas um valor reativo, enquanto observe() observa todos os valores reativos no seu interior. Utilizamos a função updateTextInput() para mudar o valor contido na caixa de texto.

output$plot = renderPlot({
  ggplot(df(), aes(x = x, y = y)) + geom_point() + 
    geom_smooth(method = "lm", se = FALSE) + 
    ggtitle(input$titulo)
})

observeEvent(input$limpar, {
  updateTextInput(session, "titulo", value = "")
})

# com observe():

# observe({
#   input$limpar
#   updateTextInput(session, "titulo", value = "")
# })

[1] Uma lista mais completa de tipos de elementos de input e output disponíveis no Shiny pode ser encontrada aqui.

Criando nossos próprios verbos no dplyr

2017-09-29T21:50:00-03:00

Esse post é bem antigo. Muita coisa pode estar incorreta devido a novidades que aconteceram desde então, ou porque meu entendimento na época não era tão claro.

Uma das decisões que tomei como programador R esse ano foi usar as soluções do tidyverse sempre que possível, ainda que pacotes fora dele oferecessem soluções computacionalmente mais eficientes. Isso implica, naturalmente, optar pelo dplyr em vez do data.table. O motivo é que, basicamente, percebi que os recursos computacionais maiores que o dplyr consome são mais baratos que o tempo que eu levava para tentar lembrar o que os hieroglifos do data.table significavam um mês depois que haviam sido escritos.

Entretanto, senti falta de algumas conveniências do data.table, em particular, a possibilidade de alteração de colunas condicional às linhas. Considere o seguinte exemplo: descobri que, devido a alguma falha no sistema, todos os voos registrados no dia primeiro de janeiro aconteceram, na verdade, no dia 7 de setembro. Seria bem simples corrigir isso usando data.table:

library(nycflights13)
library(data.table)

dt = data.table(flights)
head(dt)
#>    year month day dep_time sched_dep_time dep_delay arr_time
#> 1: 2013     1   1      517            515         2      830
#> 2: 2013     1   1      533            529         4      850
#> 3: 2013     1   1      542            540         2      923
#> 4: 2013     1   1      544            545        -1     1004
#> 5: 2013     1   1      554            600        -6      812
#> 6: 2013     1   1      554            558        -4      740
#>    sched_arr_time arr_delay carrier flight tailnum origin dest air_time
#> 1:            819        11      UA   1545  N14228    EWR  IAH      227
#> 2:            830        20      UA   1714  N24211    LGA  IAH      227
#> 3:            850        33      AA   1141  N619AA    JFK  MIA      160
#> 4:           1022       -18      B6    725  N804JB    JFK  BQN      183
#> 5:            837       -25      DL    461  N668DN    LGA  ATL      116
#> 6:            728        12      UA   1696  N39463    EWR  ORD      150
#>    distance hour minute           time_hour
#> 1:     1400    5     15 2013-01-01 05:00:00
#> 2:     1416    5     29 2013-01-01 05:00:00
#> 3:     1089    5     40 2013-01-01 05:00:00
#> 4:     1576    5     45 2013-01-01 05:00:00
#> 5:      762    6      0 2013-01-01 06:00:00
#> 6:      719    5     58 2013-01-01 05:00:00

dt[month == 1 & day == 1, `:=`(
  month = 7,
  day = 7
)]

head(dt[, .(month, day)])
#>    month day
#> 1:     7   7
#> 2:     7   7
#> 3:     7   7
#> 4:     7   7
#> 5:     7   7
#> 6:     7   7

Infelizmente, o dplyr não possui uma forma tão conveniente de tratar esses casos. A recomendação semioficial é usar vários ifelses:

library(dplyr)

flights %>%
  mutate(
    month = ifelse(month == 1 & day == 1, 7, month),
    day = ifelse(month == 1 & day == 1, 7, day)
  ) %>%
  select(month, day)
#> # A tibble: 336,776 x 2
#>    month   day
#>    <dbl> <int>
#>  1     7     1
#>  2     7     1
#>  3     7     1
#>  4     7     1
#>  5     7     1
#>  6     7     1
#>  7     7     1
#>  8     7     1
#>  9     7     1
#> 10     7     1
#> # ... with 336,766 more rows

Opa! Ainda não está correto. Há diferenças semânticas fortes entre o := do data.table e o mutate. O data.table primeiro descobre em quais linhas as operações devem ser realizadas e só depois as executa. O código dplyr acima não: a condição no ifelse é reavaliada a cada coluna alterada. Além disso, essas operações são feitas no escopo da tabela no estado em que estava antes da execução de qualquer modificação, enquanto o mutate sempre usa seu estado mais recente. É por isso que o resultado final não é o esperado: no momento em que a linha

day = ifelse(month == 1 & day == 1, 7, day)

é executada, os valores em month já foram modificados para 7 (onde foi o caso), a condição falha e os valores armazenados em day não são alterados. No entanto, um workaround é possível: podemos criar uma coluna temporária para armazenar o resultado da condição do ifelse e apagá-la depois das modificações:

flights %>%
  mutate(
    condicao = month == 1 & day == 1,
    month = ifelse(condicao, 7, month),
    day = ifelse(condicao, 7, day),
    condicao = NULL
  ) %>%
  select(month, day)
#> # A tibble: 336,776 x 2
#>    month   day
#>    <dbl> <dbl>
#>  1     7     7
#>  2     7     7
#>  3     7     7
#>  4     7     7
#>  5     7     7
#>  6     7     7
#>  7     7     7
#>  8     7     7
#>  9     7     7
#> 10     7     7
#> # ... with 336,766 more rows

Ok, funciona, mas ainda há duas inconveniências em relação à versão data.table: primeiro, precisamos manipular diretamente uma coluna lógica temporária, e depois, ainda temos que repetir explicitamente o nome da coluna dentro dos ifelses para que o valor atual seja mantido quando a condição falhar.

Percebi, então, que o mutate é um verbo inconveniente nesse tipo de situação. Felizmente, o Tidyverse lançou, há algum tempo, o framework de tidy evaluation que permite, entre outras coisas, criar novos verbos para o dplyr com alguma facilidade. O objetivo desse post é criar verbos que funcionem de forma similar à sentença dt[cond, col := val] do data.table dentro do dplyr.

Criando o verbo `transform_where`

A solução que desenvolvi para essa situação foi o verbo transform_where. Aqui está um exemplo do seu funcionamento:

flights %>%
  transform_where(
    month == 1 & day == 1,
    month = 7,
    day = 7
  ) %>%
  select(month, day)
#> # A tibble: 336,776 x 2
#>    month   day
#>    <dbl> <dbl>
#>  1     7     7
#>  2     7     7
#>  3     7     7
#>  4     7     7
#>  5     7     7
#>  6     7     7
#>  7     7     7
#>  8     7     7
#>  9     7     7
#> 10     7     7
#> # ... with 336,766 more rows

Tão compacto quanto a versão data.table e ainda tem a vantagem de produzir código fácil de ler! E quanto código isso levou? Bem, umas dez linhas:

library(rlang)
library(purrr)

transform_where = function(.data, condition, ...) {
  condition = enquo(condition) %>% eval_tidy(.data)
  mods = quos(...)

  mods = map2(mods, names(mods), function(quoted_expr, column_name) {
    quo(ifelse(condition, !!quoted_expr, !!sym(column_name))) %>%
      eval_tidy(.data)
  })

  mutate(.data, !!!mods)
}

Ok, o código é curto, mas é críptico para quem nunca teve contato com non-standard evaluation em geral, e com o framework de tidy evaluation em particular. Vou tentar explicar com algum detalhe como isso tudo está funcionando. Primeiro, os argumentos: .data representa a tabela, condition a condição, e ..., os outros argumentos, isto é, as modificações que devem ser realizadas.

Vamos para a primeira linha.

condition = enquo(condition) %>% eval_tidy(.data)

rlang::enquo é uma função que faz alguma magia negra para guardar, numa estrutura chamada denominada quosure, a expressão que foi passada para condition, e não seu valor. Afinal, esse valor sequer é válido ainda, pois month == 1 & day == 1 não indica explicitamente em que tabela month e day estão. É aqui que entra a função rlang::eval_tidy, que executa a expressão passada a ela dentro do ambiente indicado (.data). Agora o interpretador sabe onde procurar os month e day: são colunas da tabela .data, oras! Ao final dessa linha, condition guardará um vetor lógico, com TRUE nas linhas onde a condição passou e FALSE onde falhou. Próxima linha:

mods = quos(...)

rlang::quos faz a mesma coisa que enquo, mas para uma lista de expressões toda de uma vez. No caso em que essa lista tem nomes, eles também são guardados. Faça o teste:

func = function(...) {
  print(quos(...))
}

func(a == b, c + 1)
#> [[1]]
#> <quosure: global>
#> ~a == b
#>
#> [[2]]
#> <quosure: global>
#> ~c + 1
#>
#> attr(,"class")
#> [1] "quosures"
func(x = x + 2, y = y*3)
#> $x
#> <quosure: global>
#> ~x + 2
#>
#> $y
#> <quosure: global>
#> ~y * 3
#>
#> attr(,"class")
#> [1] "quosures"

A função a seguir é o coração de todo o processo. Ela transforma uma expressão x = expr em x = ifelse(condition, expr, x). Ou seja, ela transforma assignments simples em expressões complexas envolvendo condições e ifelses, nos poupando o trabalho de digitá-los.

function(quoted_expr, column_name) {
  quo(ifelse(condition, !!quoted_expr, !!sym(column_name))) %>%
    eval_tidy(.data)
}
#> function(quoted_expr, column_name) {
#>   quo(ifelse(condition, !!quoted_expr, !!sym(column_name))) %>%
#>     eval_tidy(.data)
#> }

Essa função tem dois parâmetros: quoted_expr, uma quosure com uma expressão capturada anteriormente, e column_name, o nome da coluna em uma string. A função rlang::quo salva a expressão passada como parâmetro em uma quosure, e o operador !! faz o inverso: transforma uma quosure numa expressão. A função rlang::sym, por sua vez, transforma uma string em uma expressão (um símbolo, mais especificamente). Agora já dá pra entender a ação da seguinte linha:

quo(ifelse(condition, !!quoted_expr, !!sym(column_name)))

Imaginemos que quoted_expr é uma quosure que guarda a expressão 7 e column_name é string "month": após a ação do !!, a linha acima equivale a:

quo(ifelse(condition, 7, month))

Essa quosure resultante é passada para eval_tidy, que calcula o valor dessa expressão dentro da tabela .data. No fim, a função retorna um vetor contendo o novo valor da coluna.

Para quem não conhece, purrr::map2 é essencialmente uma generalização de lapply que toma duas listas ou vetores como argumento, além de uma função de dois parâmetros. Dados x = c(x1, x2, x3), y = c(y1, y2, y2) e f, retorna uma lista list(f(x1, y1), f(x2, y2), f(x3, y3)). Além disso, se o primeiro vetor ou lista tem names, esses names são mantidos na lista resultante. Agora já dá pra entender o trecho completo.

mods = map2(mods, names(mods), function(quoted_expr, column_name) {
  quo(ifelse(condition, !!quoted_expr, !!sym(column_name))) %>%
    eval_tidy(.data)
})

Pegamos mods, uma lista cujos names são os nomes das colunas e cujos valores são expressões, e retornamos uma nova lista com os mesmos names, nomes das colunas, mas com as colunas já calculadas a partir de um ifelse adequado.

Por último, o operador !!! é para quos o que !! é para quo: transforma uma lista de quosures em uma sequência de expressões. Então a última linha,

mutate(.data, !!!mods)

após a ação do !!!, equivale a

mutate(.data, x = vetorx, y = vetory)

onde vetorx e vetory são os resultados que foram obtidos anteriormente após a execução dos ifelses. E pronto! Após todas essas manipulações de quosures, chegamos ao resultado que queríamos!

Criando um `mutate_where`:

Eu chamei a função de transform_where ao invés de mutate_where em analogia à diferença entre as funções transform e mutate: a primeira executa no contexto inicial da tabela, e a última, sempre no contexto mais recente. O exemplo abaixo esclarece a diferença.

df = data.frame(x = 1:5)
df %>% transform(x = x + 1, y = x + 1)
#>   x y
#> 1 2 2
#> 2 3 3
#> 3 4 4
#> 4 5 5
#> 5 6 6
df %>% mutate(x = x + 1, y = x + 1)
#>   x y
#> 1 2 3
#> 2 3 4
#> 3 4 5
#> 4 5 6
#> 5 6 7

Eu criei um transform_where porque parecia atender melhor minhas necessidades, mas é possível conceber situações onde um mutate_where fosse mais conveniente. É muito mais difícil fazer isso? Não. Eis o código:

mutate_where = function(.data, condition, ...) {
  condition = enquo(condition) %>% eval_tidy(.data)
  mods = quos(...)

  mods = map2(mods, names(mods), function(quoted_expr, column_name) {
    quo(ifelse(condition, !!quoted_expr, !!sym(column_name)))
  })

  mutate(.data, !!!mods)
}

Ele é quase igual ao código do transform_where, com uma pequena diferença: não há um eval_tidy dentro da função auxiliar. Isso faz com que, ao invés de se calcular logo o valor das colunas modificadas, apenas se substitua as expressões passadas por expressões envoltas por um ifelse. Ao contrário de antes, a linha

mutate(.data, !!!mods)

não vira

mutate(.data, x = vetorx, y = vetory)

e sim

mutate(.data, x = ifelse(condition, 7, x), y = ifelse(condition, 7, y))

então essas modificações são executadas com a semântica tradicional do dplyr, isto é, usando eventualmente os valores modificados que acabaram de ser computados, em vez dos valores guardados antes da execução da função.

Qual a melhor das duas funções? Depende do contexto. No caso que abriu o post, certamente um transform_where funciona melhor. Agora imagine uma situação onde os dados de partida e chegada estivessem incorretos em algumas linhas. A variável air_time, tempo de voo, também precisará ser atualizada. Nesse caso, um mutate_where corrigindo os valores de dep_time e arr_time e recalculando air_time como essa diferença resolverá a situação, enquanto um transform_where, iria, de fato, manter a coluna air_time como estava antes. Na prática, sempre tenho as duas em mãos.

Exercício para o leitor: Uma diferença entre o meu transform_where e o funcionamento do data.table é que esse último consegue criar colunas novas, preenchendo-as com NA nas linhas onde a condição é falsa. Sinceramente, esse comportamento me desagrada, por implicar que a tabela poderá sair com formatos diferentes dependendo de uma condição de forma nada explícita. De todo modo, como poderíamos modificar transform_where para que ela tenha esse comportamento?

Partições e idiomas

2017-08-23T20:00:00-03:00

Este ano comecei a ler o livro Not Exactly: In Praise of Vagueness. O objetivo do livro é mostrar como a imprecisão é inerente às nossas tentativas de entender o mundo e como a filosofia, a linguística e a ciência da computação tentam lidar com essa questão.

Um caso simples que ilustra esse problema: como classificar a fala das pessoas em idiomas? Por que, por exemplo, o português e o espanhol são considerados idiomas diferentes, ainda que tenham muito léxico, sintaxe e história em comum? O que faz com que o português falado em Lisboa e o português falado em Natal sejam considerados o mesmo idioma, ainda que existam várias diferenças em léxico, sintaxe e fonética? Em que momento as diferenças deixam de meramente definir dialetos diferentes e passam a definir novos idiomas? Ou seja, como classificamos os dialetos em categorias maiores, idiomas, de uma forma que faça algum sentido?

Partições e relações de equivalência

Esse tipo de classificação, no jargão matemático, se chama de partição. Imagine que temos um conjunto $A$. Uma partição $P$ do conjunto $A$ seria uma coleção de subconjuntos de $A$ satisfazendo dois critérios:

Todo elemento de $A$ está em algum conjunto de $P$.
Um elemento de $A$ não pode estar em dois conjuntos diferentes de $P$ ao mesmo tempo.

Se voltarmos ao problema de dividir dialetos em idiomas, isso equivale a a impôr as seguintes restrições à nossa tarefa:

Todo dialeto pertence a algum idioma.
Um dialeto não pode pertencer a dois idiomas ao mesmo tempo.

Razoável, não? Pois bem, continuemos. Quando a partição está feita, podemos pensar que os elementos de um mesmo conjunto de $P$ têm algo em comum, são, em algum sentido, equivalentes. Matematicamente, uma partição induz uma relação de equivalência, uma relação $\equiv$ que satisfaz as seguintes propriedades:

É reflexiva: $A \equiv A$, todo $A$ está relacionado a si mesmo.
É simétrica: Para quaisquer $A$ e $B$, quando $A \equiv B$, $B \equiv A$ também. Isto é, quando A está relacionado a B, B está relacionado a A.
É transitiva: Quando $A \equiv B$ e $B \equiv C$, $A \equiv C$ também. Ou seja, quando A está ligado a B e B está ligado a C, A está ligado a C também.

Uma relação de equivalência é, em essência, uma relação que tem uma estrutura parecida com a relação familiar de igualdade. Podemos verificar que a relação “pertencer a um mesmo conjunto na partição” define uma relação de equivalência:

É reflexiva, pois todo elemento de $A$ está no mesmo conjunto de $P$ que o próprio $A$, por óbvio.
É simétrica. Dizer que $A$ e $B$ ou que $B$ e $A$ estão num mesmo conjunto dá no mesmo.
É transitiva. Quando $A$ e $B$ estão no mesmo conjunto, $B$ e $C$ estão no mesmo conjunto, $A$ e $C$ estão no mesmo conjunto também, pois do contrário $B$ teria que estar em dois conjuntos diferentes de $P$, um absurdo.

A verdade é que partições e relações de equivalência são, essencialmente, dois modos diferentes de enxergar a mesma coisa. Assim como toda partição induz uma relação de equivalência, toda relação de equivalência induz uma partição. Essa partição é feita de modo intuitivo: colocamos dois elementos num mesmo conjunto quando eles são equivalentes (segundo a relação de equivalência que estabelecemos). Cada conjunto desses é denominado uma classe de equivalência, e a partição é a coleção formada por todas essas classes de equivalência.

Para exemplificar: peguemos o conjunto $A = \{0, 1, 2, 3, 4, 5, 6, 7, 8, 9\}$. Uma relação de equivalência que podemos definir sobre ele é a seguinte: chamaremos dois elementos desse conjunto de equivalentes quando o resto da divisão deles por 2 for o mesmo. Essa relação induz uma partição: podemos formar a classe de equivalência de todos os elementos cujo resto da divisão por 2 é 0, $\{0, 2, 4, 6, 8\}$ e a classe de equivalência dos elementos que deixam resto 1, $\{1, 3, 5, 7, 9\}$. Ou seja, a relação de equivalência que defini particionou o conjunto em dois, os pares e os ímpares.

A matemática nos permite concluir o seguinte: para construir partições, podemos pensar em critérios, relações de equivalência. Mas para isso, é necessário que esse critério satisfaça reflexividade, simetria e, em especial, transitividade.

Inteligibilidade mútua

Bem, temos que pensar em um critério para distinguir entre dialetos e idiomas. O mais simples que se pode pensar é o da inteligibilidade mútua: dois dialetos fazem parte de um mesmo idioma se os falantes de um, sem treinamento ou exposição prévia, conseguem se comunicar sem muitos problemas com os do outro, e vice-versa. Razoável, se pensarmos que o papel fundamental da linguagem é de mediar a comunicação.

Segundo a teoria matemática construída, esse critério só vai funcionar se for transitivo, o que infelizmente não é o caso. Um exemplo onde a inteligibilidade mútua falha em ser transitiva é o caso de contínuo de dialetos. Tipicamente os dialetos tendem a ir se diferenciando conforme a distância geográfica. Um dialeto A é parecido com um dialeto B falado a 100km, que é parecido com dialeto C a 100km de B, e assim vai. Essas diferenças vão se acumulando de tal forma que uma hora chegaremos em um dialeto Z que já não conversa mais com o dialeto A.

A península ibérica fornece um exemplo: O português do sul entende o português do norte, o português do norte entende o galego, já na Espanha, o galego entende o falante de leonês, que entende o falante de castelhano. Mas o português não é mutuamente inteligível com o castelhano! Se galego é um dialeto de português ou um idioma a parte é uma questão que ainda gera debates, e qualquer resposta a favor de um lado ou de outro será arbitrária.

Podemos modificar nosso critério para tentar resolver o problema da transitividade. Dizemos que dois dialetos são de um mesmo idioma quando são mutuamente inteligíveis ou quando, ao menos, existe uma variadade padronizada, uma versão lingua franca dele que os falantes de ambos dialetos entendem e podem usar para se comunicar. É o que acontece com o árabe, o mandarim e o alemão, por exemplo. Isso implica, no entanto, aceitar que o cantonês e o chinês de Shanghai são o mesmo idioma, embora uma conversa entre falantes das duas variedades seja inviável.

Poderíamos levar isso mais adiante: poderíamos dizer que dois dialetos A e B são de um mesmo idioma se existe uma sequência de dialetos A, C, D, E, …, B onde cada dialeto é mutuamente inteligível com o próximo. Matematicamente, a solução é perfeita. Mas a consequência é que com esse critério teríamos apenas um punhado de idiomas no mundo: o indo-europeu, o semita, o austronésio e etc. E de que adiantaria um critério tão amplo como esse? Nada. Não tem jeito: sem transitivade, qualquer critério vai pecar por falta ou excesso.

Como eu consegui descobrir a localização dos meus matches no Tinder (ou quase)

2017-06-05T15:00:00-03:00

Esse post é bem antigo. Muita coisa pode estar incorreta devido a novidades que aconteceram desde então, ou porque meu entendimento na época não era tão claro.

Eu já havia percebido uma possível vulnerabilidade de segurança no Tinder havia um tempo. Ele permite que você saiba as distâncias em que outros usuários se encontram em relação a você. Embora pareçam inofensivas, informações sobre distâncias, somadas a um pouco de perspicácia, permitem descobrir a posição exata de qualquer pessoa. Para isso, usa-se uma técnica chamada trilateração. Evidentemente, não fui o primeiro a pensar neste problema: a técnica é usada no GPS, por exemplo, e também já foi empregada com precisamente a mesma finalidade que a minha pela Include Security.

De todo modo, precisava de um tema para o projeto da disciplina de Cálculo Numérico este semestre e essa ideia parecia viável (dadas as minhas limitações de tempo) e suficientemente divertida, e cá estamos. Este artigo vai explicar como defini matematicamente o problema, utilizei programação para implementar um protótipo e quais conclusões obtive, além de uma visualização como a do header acima.

A ideia

A técnica é baseada em geometria elementar. Consideremos, inicialmente, que a terra é perfeitamente plana. Imagine que um contato está a uma distância de 5 quilômetros de você, que se encontra no ponto A. O conjunto de possíveis localizações dele determina uma circunferência de 5km de raio. Agora você vai para uma segunda posição B e verifica novamente a distância dita pelo aplicativo, que agora é de 7km. Se o problema for bem posto, tipicamente a busca será reduzida para duas possibilidades:

Movendo-se para uma terceira localização, basta comparar a distância fornecida pelo aplicativo com a distância aos dois pontos que restaram, e será possível eliminar o caso falso. Pronto, localização descoberta! Claro, você deve ter algumas objeções agora:

A distância fornecida pelo Tinder é arredondada, não é a distância real. No aplicativo não, mas a Pynder, API pirata do Tinder para Python, permite pegar a distância com precisão dupla. Se essa distância for a correta, estamos bem.
A premissa de que a pessoa não se move enquanto mudamos de posição é muito forte! De fato, mas a verdade é que esse deslocamento nunca será feito na prática. A API nos permite definir nossa latitude e longitude de forma arbitrária, sem precisarmos ter nos movido de fato.
A terra não é plana, Luiz. Claro, tanto que irei modelar a Terra como uma esfera ao longo do texto. Apesar disso, em muitos aspectos a geometria da superfície da esfera é análoga a do plano, quando os conceitos envolvidos são corretamente correspondidos, e essa intuição é de muito uso.

A formulação matemática do problema

A terra será modelada como uma esfera de raio 6378.008km, que é o valor calculado para o raio médio da Terra a partir do elipsoide WGS-84. A precisão obtida será, obviamente, menor que aquela que eu teria caso usasse o próprio WGS-84, mas ao menos para esse projeto o trade-off entre 0.5% de precisão e o grande ganho em simplicidade das contas compensa. A posição de um ponto na superfície dessa esfera é especificada por uma latitude e uma longitude, costumeiramente representados pelas letras $\phi$ e $\lambda$, respectivamente.

Neste caso, o ângulo central $\Delta\sigma$ entre os pontos $\phi_1, \lambda_1$ e $\phi_2, \lambda_2$ é dado pela fórmula

\[\Delta\sigma((\phi_1, \lambda_1), (\phi_2, \lambda_2))=\arccos\bigl(\sin\phi_1\cdot\sin\phi_2+\cos\phi_1\cdot\cos\phi_2\cdot\cos(\Delta\lambda)\bigr)\]

Para obter a distância de fato, basta multiplicar este ângulo pelo raio $r_T$ da Terra. Medições são feitas em três pontos $A = (\phi_A, \lambda_A)$, $B = (\phi_B, \lambda_B)$ e $C = (\phi_C, \lambda_C)$ arbitrários. A única restrição é que os três pontos não sejam colineares, ou melhor, que não estejam na mesma geodésia, o análogo ao conceito de reta quanto falamos da superfície da Terra. Isso deve ser observado porque, neste caso, o terceiro ponto é inútil para distinguir entre a posição real a posição falsa, pois as distâncias observadas serão as mesmas.

O objetivo é descobrir qual o ponto $P = (\phi^{\ast}, \lambda^{\ast})$ com medições de distância $d_A = r_T\Delta\sigma(P, A)$, $d_B = r_T\Delta\sigma(P, B)$ e $d_C = r_T\Delta\sigma(P, C)$. Definindo a função $F(X) = (r_T\Delta\sigma(X, A) - d_A, r_T\Delta\sigma(X, B) - d_B)$, vê-se claramente que o ponto que estamos procurando é uma raiz de F. Portanto, podemos nos concentrar em encontrar as soluções $S = \{P_1, P_2\}$ da equação $F(X) = 0$.

Por último, devemos usar o terceiro ponto para fazer uma escolha entre as duas opções que restaram. A localização final é dada por $argmin_{P \in S} {| r_T\Delta\sigma(P, C) - d_C|}$. Note que, em termos estritamente matemáticos, a solução final deveria ser o ponto $P_1$ ou $P_2$ que satisfizesse $r_T\Delta\sigma(P, C) = d_C$ de forma exata, mas admitimos uma imprecisão devido aos métodos numéricos envolvidos no processo.

A coleta dos dados

Para a coleta dos dados eu usei a API Pynder. O script é bastante simples e não precisa de muitos comentários. Em linhas gerais, capturo as informações de nome, foto, última hora em que seu posicionamento foi atualizado, e faço três medições a partir de pontos mais ou menos arbitrários. No fim, jogo tudo isso para a saída padrão como JSON.

# py/get_coords.py

import pynder
import json

# lê id e senha da entrada padrão
facebook_id = input()
facebook_token = input()

# loga
session = pynder.Session(facebook_id = facebook_id,
                         facebook_token = facebook_token)

# pega o posicionamento atual
lat = session.profile._data['pos']['lat']
lng = session.profile._data['pos']['lon']

data = dict()
data['pos1'] = [lat, lng]
data['pos2'] = [lat - .25, lng - .25]
data['pos3'] = [lat - .25, lng]
data['matches'] = []

# varre os matches coletando infos e distâncias ao ponto atual
for match in session.matches():
    photos = match.user.get_photos()
    picture = photos[0] if (len(photos) > 0) else "egg.png"

    data['matches'].append({
        'name': match.user.name,
        'picture': picture,
        'last_online': match.user.ping_time,
        'dist1': match.user.distance_km
    })

# segunda medição: atualiza a posição e pega as novas distâncias
session.update_location(lat - .25, lng - .25)

i = 0
for match in session.matches():
    data['matches'][i]['dist2'] = match.user.distance_km
    i += 1

# terceira medição: atualiza a posição e pega as novas distâncias
session.update_location(lat - .25, lng)

i = 0
for match in session.matches():
    data['matches'][i]['dist3'] = match.user.distance_km
    i += 1

# joga os dados coletados na saída padrão
print(json.dumps(data))

A solução numérica

Queremos encontrar a raiz de uma função $F$ que foi definida de um modo bastante complicado. Parece trabalhosa (provavelmente impossível) de resolver analiticamente, isto é, utilizando somente manipulações algébricas. No entanto, é possível encontrar aproximações para as raízes usando métodos numéricos. Neste caso, podemos usar uma versão do método de Newton.

A ideia é simples. Damos um chute inicial $X_0$ de onde a raiz deve estar e, chegando lá, usamos informações sobre a função e suas derivadas parciais para estimar onde a raiz dessa função deveria estar localizada caso a função variasse de um modo linear. Claro, a função não é realmente linear, mas ao menos devemos ficar mais perto da raiz do que estávamos antes. Com isso, chegamos ao um novo ponto $X_1$. Repetimos esse processo até que nos demos por satisfeitos.

Matematicamente, a relação entre um chute e o próximo é expressa por $X_{n+1} = X_n - J_F (X_n)^{-1} F(X_n)$, onde $J_F$ é a jacobiana de $F$. Essa relação sugere claramente o uso de um loop. No código abaixo, eu defino dist, que é essencialmente a função $F$ definida anteriormente, sem a subtração das distâncias medidas. A partir dela, crio uma função que gera as funções $F$ para cada contato em que estamos interessados, que nada mais são que deslocamentos da dist original. Defino também a jacobiana e a função para calcular a raiz de F usando o método de Newton. Programei o método de Newton de modo a parar quando já estiver dando passos menores que $10^{-12}$ ou já tiver dado mais de 20000 passos.

# R/newton.R

dist = function(P, A, B) {
  lat = radians(P[1])
  lng = radians(P[2])
  lat_i = radians(c(A[1], B[1]))
  lng_i = radians(c(A[2], B[2]))

  cosines = sin(lat_i)*sin(lat) + cos(lat_i)*cos(lat)*cos(lng - lng_i)
  EARTH_RADIUS * acos(cosines)
}

jacobianOfDist = function(P, A, B) {
  lat = radians(P[1])
  lng = radians(P[2])
  lat_i = radians(c(A[1], B[1]))
  lng_i = radians(c(A[2], B[2]))

  cosines = sin(lat_i)*sin(lat) + cos(lat_i)*cos(lat)*cos(lng - lng_i)

  dlat = EARTH_RADIUS * (-sin(lat_i)*cos(lat) + cos(lat_i)*sin(lat)*cos(lng - lng_i)) / sqrt(1 - cosines*cosines)
  dlng = EARTH_RADIUS * cos(lat_i)*cos(lat)*sin(lng - lng_i) / sqrt(1 - cosines*cosines)

  cbind(dlat, dlng)
}

getDistFunction = function(dist0, A, B) {
  dist0

  function(P) {
    dist(P, A, B) - dist0
  }
}

getJacobianFunction = function(A, B) {
  function(P) {
    jacobianOfDist(P, A, B)
  }
}

newton = function(f, x0, j, epsilon = 1E-12, max = 20000) {
  oldGuess = x0

  for (i in 1:max) {
    guess = oldGuess + solve(j(oldGuess), -f(oldGuess))

    if (norm(guess - oldGuess, type = "2") < epsilon)
      break
    oldGuess = guess
  }

  guess
}

Uma questão ainda ficou em aberto: precisamos das duas raízes, mas o método de Newton só encontra uma delas. Pra ser mais preciso, a raiz que o método de Newton encontra depende exclusivamente do chute inicial que damos. O problema é que, no caso geral, é muito difícil identificar para qual das raízes o sistema vai convergir dependendo do chute inicial. De primeira pensei em dar chutes iniciais aleatórios. Ora, a estrutura do problema parece bastante simétrica, fifty-fifty e seria improvável que, partindo de pontos iniciais aleatórios, eu chegasse sempre na mesma raiz. Uma hora o método vai ter que me dar as duas raízes!

Funcionou, mas resolvi pensar um pouco mais sobre a simetria do problema. Consegui provar, por exemplo, que as duas raízes são reflexões uma da outra em torno da geodésia que liga A a B. Uma intuição que tive é que, se dermos chutes iniciais refletidos em torno dessa geodésia, cada chute inicial deveria resultar numa raiz diferente. Não consegui provar esse fato, mas a intuição pareceu funcionar na prática. Se $A = (\phi_A, \lambda_A)$ e $B = (\phi_B, \lambda_B)$, dou chutes iniciais em $(\phi_A, \lambda_B)$ e $(\phi_B, \lambda_A)$. Se a terra fosse plana, estes quatro pontos formariam um quadrado e os chutes iniciais seriam reflexões um do outro. A terra não é plana, mas a figura formada fica muito perto de ser um quadrado quando os pontos A e B são escolhidos suficientemente próximos. Na prática, esses chutes funcionaram e consegui obter as duas raízes deste modo.

O resultado final

Para visualizar os resultados, criei um aplicativo Shiny usando o pacote Leaflet, que permite a criação de mapas interativos. Os cálculos dos pontos são feitos no arquivo global.R utilizando as ideias descritas acima:

# global.R
library(shiny)
library(shinydashboard)
library(purrr)
library(jsonlite)
library(leaflet)
library(glue)

source("R/newton.R", encoding = "UTF-8")

EARTH_RADIUS = 6371.008

data = fromJSON("out.json")
matches = data$matches

pos1 = data$pos1
pos2 = data$pos2
pos3 = data$pos3

# gera as funções objetivo e a jacobiana
funcs = map(1:n, ~ getDistFunction(c(matches$dist1[.], matches$dist2[.]), pos1, pos2))
jacobian = getJacobianFunction(pos1, pos2)

# calcula numericamente as duas possíveis soluções
solution1 = map(funcs, newton, j = jacobian, x0 = c(pos1[1], pos2[2]))
solution2 = map(funcs, newton, j = jacobian, x0 = c(pos2[1], pos1[2]))

decide = function(p1, p2, d, p3) {
  distances = dist(p3, p1, p2)

  if (abs(distances[1] - d) < abs(distances[2] - d))
    p1
  else
    p2
}

definiteSolution = pmap(list(solution1, solution2, matches$dist3), decide, p3 = pos3)

matches$lat = map_dbl(1:n, ~ definiteSolution[[.]][1])
matches$lng = map_dbl(1:n, ~ definiteSolution[[.]][2])

O código dos outros arquivos não é muito interessante.

# ui.R
dashboardPage(
  dashboardHeader(title = "Match Locator"),
  dashboardSidebar(disable = TRUE),
  dashboardBody(
    fluidRow(
      column(width = 12,
        box(title = "Mapa", width = NULL,
          leafletOutput("mapa", height = 600),
          solidHeader = TRUE, status = "primary"
        )
      )
    )
  )
)

# server.R
function(input, output, session) {
  output$mapa = renderLeaflet({
    leaflet() %>%
      addTiles() %>%
      addMarkers(lat = matches$lat, lng = matches$lng, popup = matches$name,
                 icon = icons(matches$picture, iconWidth = 32, iconHeight = 32))
  })
}

O importante é que isso me gerou a seguinte visualização no mapa:

Aparentemente as posições encontradas fazem sentido. Não tem ninguém dentro da floresta da tijuca ou da Baía de Guanabara, por exemplo. Quando dei zoom maior, no entanto, vi que havia uma moça usando o Tinder enquanto morria afogada… ou então o método que falhou mesmo.

Fui investigar a questão mais um pouco e montei uma tabela com as diferenças entre as distâncias medidas pelo Tinder e as distâncias dos pontos que obtive em relação aos pontos A, B e C onde das medições foram feitas. Se tudo estivesse correto, esta diferença deveria ser muito próxima de zero. Isso aconteceu com as distâncias até A e B, afinal, foi para isso que usei o método de Newton. No entanto, quando comparados com o ponto C, a distância real do ponto encontrado e a distância dada pelo Tinder diferiam, na média, em 624m. Erros desta magnitude não deveriam acontecer mesmo levando em consideração que estou aproximando a Terra por uma esfera e não por um elipsoide.

Não tenho como confirmar minhas suspeitas, mas acredito que o Tinder fornece as distâncias reais somadas a um ruído aleatório de magnitude menor que 1km. Esse ruído muda muito pouco a vida do usuário comum, que afinal lê as distâncias arredondadas, mas é suficiente para impedir que alguém com acesso a API possa usá-la para localizar alguém. Essa é uma ideia que me parece até mais inteligente que dar acesso ao valor arredondado da distância pela API, como faziam antes, pois neste caso ainda seria possível conseguir uma boa estimativa da localização do usuário usando uma quantidade grande de medições. De todo modo, os resultados que obtive parecem precisos o suficiente ao menos para ter uma ideia do bairro onde os seus matches estão.

Conclusão: Parece que o Tinder já tinha ouvido a Include Security e bolou um mecanismo inteligente que elimina essa brecha.

Conclusão atualizada (29/08/2018): Na verdade a equipe do Tinder bolou uma solução ainda melhor do que a que havia comentado antes. Na época, suspeitava que a posição real fosse somada a um ruido aleatório. Isso preveniria ataques que exploram a descontinuidade dos arredonamentos, mas ainda deixaria suscetível à Lei dos Grandes Números. A solução implementada contorna isso. Ver aqui.

Try it yourself!

Caso você tenha algum conhecimento de R e Python, você pode testar o protótipo que desenvolvi, cujo código está disponível neste repositório. Primeiro, você vai precisar usar o script py/auth.py para pegar o auth token do facebook. Pegue também o seu id do Facebook nesse site. Crie um arquivo texto contendo o id na primeira linha e o auth token na segunda. Depois, rode o seguinte comando:

python py/get_coords.py < arquivo.txt > out.json

Isso bastará para gerar o arquivo JSON contendo as informações do Tinder. Por último, basta rodar o aplicativo Shiny e ver os resultados. O uso do RStudio é bem conveniente para isso. Para rodar tudo, você precisará dos pacotes RoboBrowser, Pynder e lxml no Python e shiny, shinydashboard, purrr, jsonlite e leaflet no R.

Writing a simple symbolic computation system using R (Part 2/4)

2017-05-29T22:30:00-03:00

This post is very old. Many things may be wrong due to things that happened since then, or because I did not have a good understanding of what I was writing about.

This post was originally written in portuguese.

Today, I’m going to show how we can extend the little language we built in the previous post, enabling us to define new functions from existing ones using sums, products, and compositions.

As a starting point, it might be useful to get the code as finished on the last post. It’s available here.

Defining sums and products

The + and * operators are generic functions. This means that we can specify how they should behave when applied to arguments having a class we defined. In our case, we can define methods for these operators when applied to arguments of the symbolic class. This allows us to manipulate our functions as naturally as we manipulate vectors.

Knowing this, we can define the first draft of our method for adding functions. Also, we can already implement a simplification: when one of the operands is null, we return the other operand. It’s also easy to implement a convenience: when one of the operands is a numerical value, we convert it to a symbolic function. This way we can avoid unnecessary calls to Const().

# I added the is_symbolic(x) check on is_{type}() function to avoid errors in
# the case the object isn't even symbolic
is_nullf = function(x) is_symbolic(x) && x%@%"type" == "null" # etc

`+.symbolic` = function(f, g) {
  # we check the size of the vector because there's no intuitive idea of how
  # they should be handled when they're not scalars
  if (is.numeric(f) && length(f) == 1) 
    return(Const(f) + g)
  if (is.numeric(g) && length(g) == 1)
    return(f + Const(g))
  
  if (is_nullf(f))
    return(g)
  if (is_nullf(g))
    return(f)
  
  symbolic(
    f = function(x) f(x) + g(x),
    repr = glue("{f} + {g}"),
    df = D(f) + D(g),
    type = "sum",
    params = list(f, g)
  )
}

Mono(1, 2) + Mono(1, 1)
#> x -> 1*x^2 + 1*x^1
D(Mono(1, 2) + Mono(1, 1))
#> x -> 2*x^1 + 1
Mono(1, 2) + Log + 4
#> x -> 1*x^2 + log(x) + 4
D(Mono(1, 2) + Log + 4)
#> x -> 2*x^1 + 1*x^-1
Mono(1, 2) + 0
#> x -> 1*x^2
3 + Mono(1, 1)
#> x -> 3 + 1*x^1
0 + Mono(1, 2)
#> x -> 1*x^2

Notice that we define the sum of functions and its derivative in a very natural manner. It’s almost a mathematical definition :)

An interesting convenience we can add is a Sum function to sum an entire list of functions. With it, we might be able to operate them in chains built with the %>% operator. We don’t even have to write much code to do it: using reduce, from the package purrr[1], suffices. You pass a list of arguments to this function and a function that takes two operands. It applies the operation to the first two elements of the list, stores the result, applies it and the third element to the function, stores the result, and so on, until the list is exhausted.

Sum = function(l) reduce(l, `+.symbolic`)

Sum(list(3, Mono(1, 2), Log, Exp))
#> x -> 3 + 1*x^2 + log(x) + exp(x)

Now we can easily define an important class of functions: polynomials. Polynomials are, in fact, mere sums of monomials, so it’s not hard to define an auxiliary function to create them. We use two more functions from purrr. as_vector converts a list to a vector, and map2 is a generalization of lapply for functions that take two parameters.

Poly = function(...) {
  coef = as_vector(list(...))
  degree = length(coef) - 1
  map2(coef, degree:0, function(a, n) Mono(a, n)) %>% Sum
}

Poly(1, -5, 6)
#> x -> 1*x^2 + -5*x^1 + 6
Poly(1, 3, 3, 1)
#> x -> 1*x^3 + 3*x^2 + 3*x^1 + 1
# the representations are clearly unsatisfatory, but this is something we're going
# to fix only in the last post of the series.

Defining products is analogous to defining sums. The main difference lies in the fact that there are two elementary simplifications we can apply: the cases where one of the operations is 0 or 1.

`*.symbolic` = function(f, g) {
  if (is.numeric(f) && length(f) == 1) 
    return(Const(f) * g)
  if (is.numeric(g) && length(g) == 1)
    return(f * Const(g))  
  
  if (is_nullf(f) || is_nullf(g)) 
    return(Null)
  
  if (is_const(f) && attr(f, "params")$c == 1)
    return(g)
  if (is_const(g) && attr(g, "params")$c == 1)
    return(f)
  
  symbolic(
    f = function(x) f(x) * g(x),
    repr = glue("({f})*({g})"), 
    df = D(f)*g + f*D(g), # the product rule
    type = "product",
    params = list(f, g)
  )
}

Prod = function(l) reduce(l, `*.symbolic`)

Mono() * Exp
#> x -> (1*x^1)*(exp(x))
D(Mono() * Exp)
#> x -> exp(x) + (1*x^1)*(exp(x))
Log * Mono()
#> x -> (log(x))*(1*x^1)
D(Log * Mono())
#> x -> (1*x^-1)*(1*x^1) + log(x)

Defining compositions

Function composition is an operation that requires paying attention to many subtleties when implementing. We’ll start from the most simple of them: representation. So far we were defining the expressions using “x” directly. It’s wise to redefine them in terms of a placeholder, which might come to be “x” or an specific “f(x)” in the case of a function composition. To do this, we only need to redefine the repr attribute in terms of {x}: the glue function will take care of the details. Special attention must be paid in the case repr is parameterized. In this case, we should use {{x}}, because glue is going to be evaluated two times, at two different moments: one with the usual parameters of repr, as soon as the function is defined, and another time, with the placeholder instead of x, when as.character is called.

The changes that must be applied are shown below:

# Mono's representation: line 68
# before: 
  repr = glue("{a}*x^{n}")
# after:
  repr = glue("{a}**^{n}")
  
# Log's representation: line 79
# before:
  repr = "log({x})"
# after:
  repr = "log({x})"
  
# Exp's representation: Line 89
# before:
  repr = "exp(x)"
# after:
  repr = "exp({x})"
  
# `+`'s representation: 
# before:
  repr = glue("{f} + {g}")
# after:
  repr = glue('{f%@%"repr"} + {g%@%"repr"}')

# `*`'s representation: 
# before:
  repr = glue("({f})*({g})")
# after:
  repr = glue('({f%@%"repr"})*({g%@%"repr"})')
  
  
# changes on as.character: line 19
# before:
  as.character.symbolic = function(f) f%@%"repr"
# after:
  as.character.symbolic = function(f) glue(f%@%"repr", x = "x")

Now representing function composition becomes trivial. If, for instance, f%@%"repr" is 1*{x}^2 + exp({x}), the line glue(f%@%"repr", x = "sin(x)") will give the representation of the composition of itself with the sine function.

Second problem: there’s no operator, defined as an R generic function, natural enough to use as a composition operator. There’s no ° operator. It seems defining a Compose function is the best we can do. Or not! It’d be great if we could compose functions by nesting them, such as Log(Sin). Is it possible? Yes, it is!

To do that we need to make quite deep changes to symbolic() nonetheless. Currently, it simply preserves the function f, passed as parameter, as is. We can do better. We can construct a new function, g, from it, such that g(x) equals f(x) when the argument is numeric, but g(x) returns a function composition when x is, itself, a symbolic function. For instance, Log(4) is evaluated as a number, but Log(Sin) is interpreted as a function composition.

It’s quite inconvenient but, to do that, we need the variable or auxiliary function (Mono, Exp, etc) that generates the functions. To store it, one more argument to symbolic() will be needed, which we’ll call this. Naturally, we’ll need to add a this parameter to the calls to symbolic() on the functions we’ve already defined.

The new code for symbolic() and the code for Compose() can be found below. Their operation is quite sophisticated, so I recommend that you spend a little time testing it and figuring out what’s happening on the execution.

symbolic = function(f, repr, df, type, this, params = list(), inverse = NULL) {
  this = lazy(this) # stores the expression
  
  g = function(x) {
    if (is_symbolic(x)) {
      this = lazy_eval(this) # executes it
      # if it comes from a function thas does not take parameters (Sin ou Exp, for instance)
      if (is_symbolic(this))
        return(Compose(this, x)) # we can use it directly on the composition
      
      # if it has parameters, calls the function that generates it with the 
      # parameters
      s = do.call(this, params)
      return(Compose(s, x))
    }

    # if x is not symbolic, simply evaluates the function at that point
    f(x)
  }
  
  class(g) = c("symbolic", "function")
  attr(g, "repr") = repr # a string representation of the function
  attr(g, "df") = lazy(df) # its derivative
  attr(g, "inverse") = lazy(inverse) # its inverse. We're not gonna use it yet.
  attr(g, "type") = type # what kind of function this is
  attr(g, "params") = params # the parameters which define a function of this type
  g
}

has_inverse = function(f) !is.null(f%@%"inverse")
inverse = function(f) lazy_eval(f%@%"inverse")

Compose = function(f, g) {
  if (is_nullf(f) || is_const(f))
    return(f)
  
  # if g(x) = c, f(g(x)) = f(c)
  if (is_nullf(g))
    return(Const(f(0)))
  
  if (is_const(g))
    return(Const(f(attr(g, "params")$c)))
  
  symbolic(
    f = function(x) f(g(x)),
    # an extra pair of parentheses for precaution. Fow now it's better to use
    # potentially more parentheses than necessary
    repr = glue(f%@%"repr", x = glue("({g})")), 
    df = D(f)(g) * D(g), # chain rule
    type = "composition",
    this = Compose,
    params = list(f, g),
    inverse = if (has_inverse(f) && has_inverse(g)) 
        inverse(g)(inverse(f))
      else 
        NULL
  )
}

Remember to add the this parameter! For instance, the new definition of Null is:

Null = symbolic(
  f = function(x) 0,
  repr = "0",
  df = Null,
  type = "null",
  this = Null
)

Let’s do some testing:

Mono(1, 2)
#> x -> 1*x^2
Mono(1, 2)(3)
#> [1] 9
Mono(1, 2)(Const(3))
#> x -> 9
Mono(1, 2)(Exp)
#> x -> 1*(exp(x))^2
D(Mono(1, 2)(Exp))
#> x -> (2*(exp(x))^1)*(exp(x))
Poly(1, 2, 3)
#> x -> 1*x^2 + 2*x^1 + 3
Poly(1, 2, 3)(0)
#> [1] 3
Poly(1, 2, 3)(Null)
#> x -> 3
Poly(1, 2, 3)(Log)
#> x -> 1*(log(x))^2 + 2*(log(x))^1 + 3
D(Poly(1, 2, 3)(Log))
#> x -> (2*(log(x))^1 + 2)*(1*x^-1)
D(Poly(1, 2, 3)(Log), 2)
#> x -> ((2)*(1*x^-1))*(1*x^-1) + (2*(log(x))^1 + 2)*(-1*x^-2)

Except for the extremely long representations, everything seems to be working just fine :)

New functions

Before attacking the representation and simplification problems, there are more things we can add to the system with ease. We can define, for instance, subtraction and division operators. We’re going to represent -g as the composition of x -> -x (that is, Mono(a = -1)) with g, and f - g as f + (-g), where -g follows the previous definition. By analogy, we’ll define f / g as f times the composition of Mono(n = -1) with g, that is, the reciprocal of g.

`-.symbolic` = function(f, g) {
  # unary minus
  if (missing(g)) {
    Mono(a = -1)(f)
  } else {
    f + (-g)
  }
}

`/.symbolic` = function(f, g) f * Mono(n = -1)(g)

Log - Exp
#> x -> log(x) + -1*(exp(x))^1
Log / Exp
#> x -> (log(x))*(1*(exp(x))^-1)

Now we can define trigonometric functions:

Sin = symbolic(
  f = sin,
  repr = "sin({x})",
  df = Cos,
  type = "sin",
  this = Sin
)

Cos = symbolic(
  f = cos,
  repr = "cos({x})",
  df = -Sin,
  type = "cos",
  this = Cos
)

Sin(0)
#> [1] 0
Cos(0)
#> [1] 1
D(Sin)
#> x -> cos(x)
D(Sin, 2)
#> x -> -1*(sin(x))^1
D(Sin, 3)
#> x -> (-1)*(cos(x))
D(Sin, 4)
#> x -> (-1)*(-1*(sin(x))^1)

Of course we can already define the tangent, secant and even inverse trigonometric functions, such as the arctangent. I’ll let them as an exercise to the reader.

Part 1/4: Building the system’s structure
Part 3/4: Adding algebraic simplifications
Part 4/4: Producing smarter string representations

The code as found at the end of this post can be viewed here.

[1] Base R also has a Reduce function doing the same task, but I find the functions from purrr more consistent and convenient.

Escrevendo um pequeno sistema de computação simbólica em R (Parte 2/4)

2017-05-19T21:38:00-03:00

Esse post é bem antigo. Muita coisa pode estar incorreta devido a novidades que aconteceram desde então, ou porque meu entendimento na época não era tão claro.

An english version of this post is available here.

No post de hoje irei mostrar como estender a pequena linguagem desenvolvida no post anterior para que possamos definir novas funções a partir das existentes usando somas, produtos e composições.

Como ponto de partida, é útil pegar o código como foi finalizado no último post. Ele está disponível aqui.

Definindo soma e produto

Os operadores + e * são funções genéricas. Isso significa que podemos definir como eles devem funcionar quando os operandos são de uma classe que definimos. No nosso caso, podemos definir métodos para esses operadores quando aplicados em argumentos do tipo symbolic. Isso permite que manipulemos nossas funções com a mesma naturalidade com que manipulamos vetores.

Sabendo disso, podemos definir o primeiro rascunho do método para somar funções. Já é possível implementar, também, uma simplificação: quando um dos operandos for nulo, retornamos o outro operando. Também é fácil implementar uma conveniência: quando um operando for um valor numérico, podemos convertê-lo a uma função constante do nosso sistema. Desse modo, podemos evitar algumas chamadas desnecessárias a Const().

# adicionei a comparação is_symbolic(x) nas funções is_{tipo}() para evitar
# erros no caso em que o objeto sequer é da classe symbolic
is_nullf = function(x) is_symbolic(x) && x%@%"type" == "null" # etc

`+.symbolic` = function(f, g) {
  # checamos o tamanho do vetor porque, no caso em que não é um escalar,
  # não há uma ideia intuitiva do que deve ser feito
  if (is.numeric(f) && length(f) == 1) 
    return(Const(f) + g)
  if (is.numeric(g) && length(g) == 1)
    return(f + Const(g))
  
  if (is_nullf(f))
    return(g)
  if (is_nullf(g))
    return(f)
  
  symbolic(
    f = function(x) f(x) + g(x),
    repr = glue("{f} + {g}"),
    df = D(f) + D(g),
    type = "sum",
    params = list(f, g)
  )
}

Mono(1, 2) + Mono(1, 1)
#> x -> 1*x^2 + 1*x^1
D(Mono(1, 2) + Mono(1, 1))
#> x -> 2*x^1 + 1
Mono(1, 2) + Log + 4
#> x -> 1*x^2 + log(x) + 4
D(Mono(1, 2) + Log + 4)
#> x -> 2*x^1 + 1*x^-1
Mono(1, 2) + 0
#> x -> 1*x^2
3 + Mono(1, 1)
#> x -> 3 + 1*x^1
0 + Mono(1, 2)
#> x -> 1*x^2

Observe a naturalidade com que criamos a função soma e a sua derivada. É praticamente uma definição matemática :)

Uma conveniência interessante é criar um método Sum para quando quisermos somar uma lista de funções. Desse modo, podemos operá-las em cadeias construídas com o operador %>%. Nem precisamos escrever muito código para isso: basta usar a função reduce, do pacote purrr[1]. Nela, você passa uma lista de argumentos e uma função com dois operandos. Ela aplica a operação nos dois primeiros elementos da lista, guarda o resultado, aplica com o terceiro elemento, e assim sucessivamente.

Sum = function(l) reduce(l, `+.symbolic`)

Sum(list(3, Mono(1, 2), Log, Exp))
#> x -> 3 + 1*x^2 + log(x) + exp(x)

Agora podemos definir com facilidade uma classe de funções importante: polinômios. Polinômios são apenas somas de monômios, então não há grande dificuldade em criar uma função auxiliar para criá-los. Usamos mais duas funções auxiliares do pacote purrr. as_vector converte uma lista em um vetor, e map2 é uma espécie de lapply para funções com dois parâmetros.

Poly = function(...) {
  coef = as_vector(list(...))
  degree = length(coef) - 1
  map2(coef, degree:0, function(a, n) Mono(a, n)) %>% Sum
}

Poly(1, -5, 6)
#> x -> 1*x^2 + -5*x^1 + 6
Poly(1, 3, 3, 1)
#> x -> 1*x^3 + 3*x^2 + 3*x^1 + 1
# as representações estão claramente insatisfatórias, mas isso é algo a ser
# resolvido no último post da série

Definir o produto é análogo a definir a soma. A diferença maior reside no fato de que há duas simplificações elementares que podem ser feitas: os casos onde um dos operandos é 0 ou 1.

`*.symbolic` = function(f, g) {
  if (is.numeric(f) && length(f) == 1) 
    return(Const(f) * g)
  if (is.numeric(g) && length(g) == 1)
    return(f * Const(g))  
  
  if (is_nullf(f) || is_nullf(g)) 
    return(Null)
  
  if (is_const(f) && attr(f, "params")$c == 1)
    return(g)
  if (is_const(g) && attr(g, "params")$c == 1)
    return(f)
  
  symbolic(
    f = function(x) f(x) * g(x),
    repr = glue("({f})*({g})"), 
    df = D(f)*g + f*D(g), # regra do produto
    type = "product",
    params = list(f, g)
  )
}

Prod = function(l) reduce(l, `*.symbolic`)

Mono() * Exp
#> x -> (1*x^1)*(exp(x))
D(Mono() * Exp)
#> x -> exp(x) + (1*x^1)*(exp(x))
Log * Mono()
#> x -> (log(x))*(1*x^1)
D(Log * Mono())
#> x -> (1*x^-1)*(1*x^1) + log(x)

Definindo composições

A composição de funções é a operação que a apresenta o maior número de sutilezas. Comecemos pela mais simples: representação. Até agora estávamos definindo as expressões de uma forma que envolvia diretamente “x”. É interessante redefini-las em termos de um placeholder, que pode vir a ser “x” ou um “f(x)”, no caso de uma composição de funções. Para isso, basta definirmos o atributo repr em termos de {x}: a função glue cuidará do resto. Atenção especial deve ser tomada no caso em que repr é parametrizado. Quando isto ocorre, deve-se usar {{x}}, pois glue será avaliada duas vezes, em dois momentos diferentes: uma com os parâmetros usuais de repr, logo que a função é definida, e outra com o placeholder no lugar de x, quando o método as.character for executado.

Seguem as modificações que devem ser feitas:

# Representação de Mono: linha 68
# antes: 
  repr = glue("{a}*x^{n}")
# depois:
  repr = glue("{a}**^{n}")
  
# Representação de Log: linha 79
# antes:
  repr = "log({x})"
# depois:
  repr = "log({x})"
  
# Representação de Exp: Linha 89
# antes:
  repr = "exp(x)"
# depois:
  repr = "exp({x})"
  
# Representação de `+`: 
# antes:
  repr = glue("{f} + {g}")
# depois:
  repr = glue('{f%@%"repr"} + {g%@%"repr"}')

# Representação de `*`: 
# antes:
  repr = glue("({f})*({g})")
# depois:
  repr = glue('({f%@%"repr"})*({g%@%"repr"})')
  
  
# Mudança no as.character: linha 19
# antes:
  as.character.symbolic = function(f) f%@%"repr"
# depois:
  as.character.symbolic = function(f) glue(f%@%"repr", x = "x")

Agora a representação de composições de funções se torna trivial. Se f%@%"repr" é 1*{x}^2 + exp({x}), por exemplo, a linha glue(f%@%"repr", x = "sin(x)") dará a representação desta função composta com a função seno.

Segundo problema: Não há nenhum operador definido como função genérica no R que seja intuitivo o suficiente para usarmos para a composição, não existe um operador °. Resta nos contentar com uma função chamada Compose ou algo do tipo. Ou não! Seria interessante que pudéssemos compor as funções usando uma notação como Log(Sin). Isso é possível? Sim!

Precisaremos, no entanto, modificar a função symbolic(). Atualmente ela simplesmente preserva a função f passada como parâmetro. Podemos fazer melhor. Podemos criar uma função nova, g, a partir dela, de modo que g(x) é f(x) em todos os casos normais (isto é, quando o parâmetro é numérico), mas g(x) é uma composição de funções no caso em que x é, ela mesma, uma função simbólica. Por exemplo, Log(4) será avaliada como um número, mas Log(Sin) como uma composição de funções.

Um detalhe um tanto inconveniente é que, para fazer isso, precisaremos ter a variável ou função auxiliar (Mono, Exp, etc) que gera as funções. Será necessário, para guardá-la, mais um argumento em symbolic(), o qual chamaremos de this. Naturalmente, teremos que adicionar um parâmetro this na chamada a symbolic() das funções que definimos anteriormente.

O novo código para symbolic() e o código para a função Compose() se encontram abaixo. O funcionamento delas é um tanto sofisticado. Portanto, recomendo que passe um tempinho testando e tentando entender o que acontece durante a execução delas.

symbolic = function(f, repr, df, type, this, params = list(), inverse = NULL) {
  this = lazy(this) # guarda a expressão
  
  g = function(x) {
    if (is_symbolic(x)) {
      this = lazy_eval(this) # executa
      # se vem de uma função que não toma parâmetros (Sin ou Exp, por ex)
      if (is_symbolic(this))
        return(Compose(this, x)) # pode usá-la diretamente na composição
      
      # se ainda há parâmetros a serem chamados, chama a função criadora
      # com esses parâmetros
      s = do.call(this, params)
      return(Compose(s, x))
    }

    # se x não for symbolic, simplesmente calcula o valor numérico da função
    f(x)
  }
  
  class(g) = c("symbolic", "function")
  attr(g, "repr") = repr # uma representação da função, como string
  attr(g, "df") = lazy(df) # a derivada da função
  attr(g, "inverse") = lazy(inverse) # a inversa da função. não será usada ainda.
  attr(g, "type") = type # que tipo de função isso é
  attr(g, "params") = params # os parâmetros que definem uma função daquele tipo
  g
}

has_inverse = function(f) !is.null(f%@%"inverse")
inverse = function(f) lazy_eval(f%@%"inverse")

Compose = function(f, g) {
  if (is_nullf(f) || is_const(f))
    return(f)
  
  # se g(x) = c, f(g(x)) = f(c)
  if (is_nullf(g))
    return(Const(f(0)))
  
  if (is_const(g))
    return(Const(f(attr(g, "params")$c)))
  
  symbolic(
    f = function(x) f(g(x)),
    # um par de parênteses a mais por precaução. Por enquanto, é preferível
    # mais parênteses que menos
    repr = glue(f%@%"repr", x = glue("({g})")), 
    df = D(f)(g) * D(g), # regra da cadeia
    type = "composition",
    this = Compose,
    params = list(f, g),
    inverse = if (has_inverse(f) && has_inverse(g)) 
        inverse(g)(inverse(f))
      else 
        NULL
  )
}

Lembre-se de inserir o parâmetro this! Por exemplo, a nova definição de Null é:

Null = symbolic(
  f = function(x) 0,
  repr = "0",
  df = Null,
  type = "null",
  this = Null
)

Façamos agora alguns testes:

Mono(1, 2)
#> x -> 1*x^2
Mono(1, 2)(3)
#> [1] 9
Mono(1, 2)(Const(3))
#> x -> 9
Mono(1, 2)(Exp)
#> x -> 1*(exp(x))^2
D(Mono(1, 2)(Exp))
#> x -> (2*(exp(x))^1)*(exp(x))
Poly(1, 2, 3)
#> x -> 1*x^2 + 2*x^1 + 3
Poly(1, 2, 3)(0)
#> [1] 3
Poly(1, 2, 3)(Null)
#> x -> 3
Poly(1, 2, 3)(Log)
#> x -> 1*(log(x))^2 + 2*(log(x))^1 + 3
D(Poly(1, 2, 3)(Log))
#> x -> (2*(log(x))^1 + 2)*(1*x^-1)
D(Poly(1, 2, 3)(Log), 2)
#> x -> ((2)*(1*x^-1))*(1*x^-1) + (2*(log(x))^1 + 2)*(-1*x^-2)

Exceto pelas representações extremamente prolixas, tudo parece estar em seu lugar! :)

Novas funções

Antes de atacar os problemas de representação e simplificação, há mais coisas que podemos adicionar sem muito trabalho. Podemos definir, por exemplo, operadores de subtração e divisão. Por motivos que ficarão mais claros mais tarde, representaremos -g como a composição de x -> -x (isto é, Mono(a = -1)) com g, e f - g como f + (-g), com -g seguindo a definição anterior. Analogamente, definimos f / g como a f multiplicado pela composição de Mono(n = -1) com g, isto é, a recíproca de g.

`-.symbolic` = function(f, g) {
  # caso do - unário
  if (missing(g)) {
    Mono(a = -1)(f)
  } else {
    f + (-g)
  }
}

`/.symbolic` = function(f, g) f * Mono(n = -1)(g)

Log - Exp
#> x -> log(x) + -1*(exp(x))^1
Log / Exp
#> x -> (log(x))*(1*(exp(x))^-1)

Agora podemos definir as funções trigonométricas:

Sin = symbolic(
  f = sin,
  repr = "sin({x})",
  df = Cos,
  type = "sin",
  this = Sin
)

Cos = symbolic(
  f = cos,
  repr = "cos({x})",
  df = -Sin,
  type = "cos",
  this = Cos
)

Sin(0)
#> [1] 0
Cos(0)
#> [1] 1
D(Sin)
#> x -> cos(x)
D(Sin, 2)
#> x -> -1*(sin(x))^1
D(Sin, 3)
#> x -> (-1)*(cos(x))
D(Sin, 4)
#> x -> (-1)*(-1*(sin(x))^1)

Claro, já podemos definir as funções tangente, secante e até as trigonométricas inversas, como arco-tangente. Isto fica como exercício para o leitor (risos). Até o próximo post!

Parte 1/4: Construindo a estrutura do sistema
Parte 3/4: Ensinando as simplificações álgebricas
Parte 4/4: Tornando a representação das funções mais inteligente

O código como encontrado ao final deste post pode ser visto aqui.

[1] Há uma função Reduce no base-R cumprindo o mesmo papel, mas acho as funções do pacote purrr mais consistentes e convenientes.

Writing a simple symbolic computation system using R (Part 1/4)

2017-05-02T21:00:00-03:00

This post is very old. Many things may be wrong due to things that happened since then, or because I did not have a good understanding of what I was writing about.

This post was originally written in portuguese.

This week I found myself thinking on how packages like dplyr use a lot of metaprogramming (that is, computation over the language itself) and functional tools to create functions having a lot of expressive power. I asked myself: can I possibly use these tools for algebraic manipulation? In particular, could I use them to build a system capable of doing symbolic differentiation?

I came up with the differentiation problem in particular because it’s clear that finding derivatives of elementary functions consists of mere formal (though tedious) manipulation. Symbolic integration, in contrast, is more an art than an algorithm.

After playing with the idea and a few days of tinkering, I figured out that doing it is not only possible, but it also can be done with relative ease. It’s an exercise that illustrates pretty well how R’s functional and metaprogramming capabilities translate to concise and expressive code.

I wanted this system, (or, being fancy, domain-specific language) to satisfy four requisites:

It must describe concisely all elementary functions from calculus, that is, anything that’s built with polynomials, exponentials, logarithms and trigonometric functions.
It must be able to manipulate them both symbolically and numerically.
It must be able to compute their derivatives symbolically.
The computed symbolic expressions must be simple, whenever possible.

Let it be clear that I’m not a symbolic computation expert, so a system for real-world use would probably need to implement a lot of optimizations to the algorithms I use.

Let’s get started, then. First, I’m going to need three packages: purrr, lazyeval, and glue, so install them if you do not have them installed yet. I’ll explain the functions as I use them.

The first tough detail is that I want functions to be callable. In other words, I want them to be evaluated using the traditional function syntax: the function name followed by a pair of parentheses enclosing its argument. At the same time, I need them to store additional data, such as a string representation, its derivative or its inverse. To do it, I’m going to need R attributes.

In R, every object can store data through attributes, setting them using attr(). To access them, you can use attr() itself or the operator %@% provided by purrr. Thus, I only need to take an ordinary mathematical function and add the data needed through attributes.

For convenience, I also define print and as.character methods for the symbolic class, so working with these functions in an interactive environment becomes more pleasurable. Finally, I’m going to create a function for computing the n-th derivative of a function symbolically.

library(purrr)
library(glue)
library(lazyeval)

symbolic = function(f, repr, df, type, params = list(), inverse = NULL) {
  class(f) = c("symbolic", "function")
  attr(f, "repr") = repr # a string representation of the function
  attr(f, "df") = lazy(df) # its derivative
  attr(f, "inverse") = lazy(inverse) # its inverse. We're not gonna use it yet.
  attr(f, "type") = type # what kind of function this is
  attr(f, "params") = params # the parameters which define a function of this type
  f
}

# auxiliary functions
is_symbolic = function(x) inherits(x, "symbolic")

as.character.symbolic = function(f) f%@%"repr"

print.symbolic = function(f) cat(glue("x -> {f}"))

# The differential operator. Takes the n-th derivative of a function recursively
D = function(f, n = 1) {
  if (n == 0) # does nothing
    f
  else if (n == 1) # for the first derivative, it only evaluates the df attribute
    lazy_eval(f%@%"df")
  else # the n-th derivative is the derivative of the (n-1)-th derivative
    D(lazy_eval(f%@%"df"), n - 1)
}

A very important tool for us, used extensively through this project, is lazy evaluation. Its usefulness will become clear when I define the first funcion with this system: the null function. We know that the derivative of the null function is the null function itself. I will define it in a seemingly circular way. Instinctively, it should result in some kind of error, but it doesn’t. Look:

Null = symbolic(
  f = function(x) 0,
  repr = "0",
  df = Null,
  type = "null"
)

is_nullf = function(x) x%@%"type" == "null"

Null
#> x -> 0
Null(5)
#> [1] 0
D(Null) # the null function itself
#> x -> 0

I’m defining Null as the result of symbolic() applied to a list of parameters, one of them being Null itself, and still it works fine? How come?

The lazy() function, used inside symbolic(), is the key. It captures the expression that defines a derivative, but does not evaluate it. In fact, I do not need to compute the derivative of a function the moment I define it, I just need to know how to compute it when I need. That’s precisely what the lazy(df) line is doing. It’s storing the expression defining the derivative so later, when I call D(), I can use lazy_eval() to obtain it.

Try running the previous code removing the references to lazy(). You’re going to get this error message:

Error in symbolic(f = function(x) 0, repr = "0", df = Null, type = "null") :
  object 'Null' not found

This happens because Null hasn’t been defined yet the moment symbolic() is called. Lazy evaluation avoids this problem. It says that, the moment I want to compute the derivative of Null, the result is going to be Null itself. But then Null will already be defined! Problem solved :)

Using the same idea, we can define a few more classes of functions:

Const = function(c) {
  if (c == 0)
    return(Null)

  symbolic(
    f = function(x) c,
    repr = as.character(c),
    df = Null,
    type = "const",
    params = list(c = c)
  )  
}

is_const = function(x) x%@%"type" == "const"

# Monomials
Mono = function(a = 1, n = 1) {
  if (a == 0)
    return(Null)

  if (n == 0)
    return(Const(a))

  symbolic(
    f = function(x) a*x^n,
    repr = glue("{a}*x^{n}"),
    df = Mono(n*a, n-1),
    type = "mono",
    params = list(a = a, n = n),
    inverse = Mono(1/a^(1/n), 1/n)
  )
}

is_mono = function(x) x%@%"type" == "mono"

Log = symbolic(
  f = log,
  repr = "log(x)",
  df = Mono(1, -1),
  type = "log",
  inverse = Exp
)

is_log = function(x) x%@%"type" == "log"

Exp = symbolic(
  f = exp,
  repr = "exp(x)",
  df = Exp,
  type = "exp",
  inverse = Log
)

is_exp = function(x) x%@%"type" == "exp"

Strictly speaking, the formula for the inverse of a monomial I gave above is valid only when the function is defined for positive numbers only. Tackling this kind of problem requires a sophistication I don’t want to engage with in this series of posts.

Now, let’s test the functions to see if everything is working fine.

f = Const(3)
f(5)
#> [1] 3
D(f)
#> x -> 0
D(f, 2)
#> x -> 0

f = Mono(0.5, 2)
f(3)
#> [1] 4.5
D(f)
#> x -> 1*x^1
D(f, 2)
#> x -> 1

f = Log
f(exp(1))
#> [1] 1
D(f)
#> x -> 1*x^-1
D(f, 2)
#> x -> -1*x^-2

f = Exp
f(1)
#> [1] 2.718282
D(f)
#> x -> exp(x)
D(f, 2)
#> x -> exp(x)

It is!

Ok, in this post we were able to define some elementary functions and compute their derivatives, but we couldn’t have much fun with them yet. Calculus becomes interesting when we can define new functions using sums, products and compositions (highlights). In the next post of this series I’m going to explain how we can add these features. See you!

Part 2/4: Defining sums, products, and compositions
Part 3/4: Adding algebraic simplifications
Part 4/4: Producing smarter string representations

Escrevendo um pequeno sistema de computação simbólica em R (Parte 1/4)

2017-05-01T21:38:00-03:00

Esse post é bem antigo. Muita coisa pode estar incorreta devido a novidades que aconteceram desde então, ou porque meu entendimento na época não era tão claro.

An english version of this post is available here.

Essa semana me peguei pensando em como pacotes como o dplyr utilizam muito recursos de metaprogramação (isto é, computação sobre a própria linguagem) para criar funções com grande poder expressivo. Me perguntei: será que é possível usar isso para manipulação algébrica? Em particular, seria possível criar uma função que, dada a descrição simbólica de uma função, computasse sua derivada?

Pensei no problema da derivada, em particular, porque é evidente que encontrar as derivadas de funções elementares é uma mera manipulação formal (embora tediosa), ao contrário da busca por antiderivadas, que está muito mais para arte que para algoritmo.

Descobri, depois de alguns dias brincando com a ideia, que isso não só é possível como é possível com relativa facilidade. É um exercício que ilustra bem como as ferramentas funcionais e de metaprogramação do R se traduzem em mais concisão e expressividade.

Quero que esta linguagem satisfaça quatro requisitos:

Possa descrever concisamente todas as funções elementares do cálculo, isto é, aquelas obtidas a partir de polinômios, trigonométricas, exponenciais e logaritmos.
Que as funções expressas possam ser manipuladas simbólica e numericamente.
Possa computar simbolicamente as derivadas destas funções.
Que as expressões simbólicas geradas sejam simples, na medida do possível.

Quero deixar claro que não sou nenhum especialista em computação simbólica e que, muito provavelmente, um sistema para uso real-world precisaria implementar várias otimizações dos algoritmos aqui usados.

Mãos à obra, então! Estou usando três pacotes: purrr, lazyeval, e glue. O uso deles será explicado ao longo do texto.

O primeiro detalhe é que quero ter uma função chamável, isto é, que eu possa avaliar f(x) diretamente para algum número, mas ao mesmo tempo preciso que ela possa armazenar mais informações, por exemplo, uma representação em string ou qual é a sua derivada. Para isso, posso usar os atributos em R.

Em R, todo objeto pode guardar dados através da função attr(). Pode-se depois acessá-los via attr() ou %@%. Então basta pegar uma função matemática ordinária em R e adicionar os dados que forem necessários a ela via atributos. Também modificarei o método print() e o as.character delas para que o trabalho com essas funções no console seja mais agradável. Por último, criarei uma função para computar simbolicamente a n-ésima derivada.

library(purrr)
library(glue)
library(lazyeval)

symbolic = function(f, repr, df, type, params = list(), inverse = NULL) {
  class(f) = c("symbolic", "function")
  attr(f, "repr") = repr # uma representação da função, como string
  attr(f, "df") = lazy(df) # a derivada da função
  attr(f, "inverse") = lazy(inverse) # a inversa da função. não será usada ainda.
  attr(f, "type") = type # que tipo de função isso é
  attr(f, "params") = params # os parâmetros que definem uma função daquele tipo
  f
}

# funções auxiliares
is_symbolic = function(x) inherits(x, "symbolic")

as.character.symbolic = function(f) f%@%"repr"

print.symbolic = function(f) cat(glue("x -> {f}"))

# função para calcular a n-ésima derivada recursivamente
D = function(f, n = 1) {
  if (n == 0) # não faz nada
    f
  else if (n == 1) # se quer a primeira derivada, apenas retorna o atributo df de f
    lazy_eval(f%@%"df")
  else # se não, calcula a n-1 ésima derivada da sua derivada
    D(lazy_eval(f%@%"df"), n - 1)
}

Uma ferramenta muito importante e usada extensivamente neste projeto é a lazy evaluation. Isto ficará claro quando eu definir a primeira função dentro deste sistema: a função nula. Sabe-se que a derivada da função nula é a própria função nula. Defino-a por uma via aparentemente circular, que intuitivamente deveria resultar em alguma espécie de erro, mas não é isso que ocorre. Veja:

Null = symbolic(
  f = function(x) 0,
  repr = "0",
  df = Null,
  type = "null"
)

is_nullf = function(x) x%@%"type" == "null"

Null
#> x -> 0
Null(5)
#> [1] 0
D(Null) # a própria função nula
#> x -> 0

Defino Null como o resultado de symbolic() aplicado a uma lista de parâmetros e um deles é o próprio Null, e mesmo assim tudo funciona corretamente? O segredo para isso é a função lazy(), que é usada no interior de symbolic(). Ela captura a expressão que define a derivada, mas não a executa. De fato, não preciso computar a derivada de uma função logo que a defino, só precisamos saber como computá-la, e é precisamente isso que lazy(df) faz. Somente em D() que preciso ter a derivada computada de fato, e lá que uso lazy_eval() para obtê-la.

Experimente rodar o código anterior retirando as chamadas a lazy(). Você irá obter a seguinte mensagem de erro:

Error in symbolic(f = function(x) 0, repr = "0", df = Null, type = "null") : 
object 'Null' not found

Isto ocorre porque Null ainda não está definido no momento em que symbolic() é chamada. A lazy evaluation cortorna isto. Ela diz que, quando eu quiser calcular a derivada de Null, basta retornar a própria Null. Só que quando isso acontecer, Null já terá sido definida. Problema resolvido :)

Podemos, então, definir mais alguns tipos de funções:

Const = function(c) {
  if (c == 0)
    return(Null)
  
  symbolic(
    f = function(x) c,
    repr = as.character(c),
    df = Null,
    type = "const",
    params = list(c = c)
  )  
}

is_const = function(x) x%@%"type" == "const"

# Monômios
Mono = function(a = 1, n = 1) {
  if (a == 0)
    return(Null)
  
  if (n == 0)
    return(Const(a))
  
  symbolic(
    f = function(x) a*x^n,
    repr = glue("{a}*x^{n}"),
    df = Mono(n*a, n-1),
    type = "mono",
    params = list(a = a, n = n),
    inverse = Mono(1/a^(1/n), 1/n) 
  )
}

is_mono = function(x) x%@%"type" == "mono"

Log = symbolic(
  f = log,
  repr = "log(x)",
  df = Mono(1, -1),
  type = "log",
  inverse = Exp
)

is_log = function(x) x%@%"type" == "log"

Exp = symbolic(
  f = exp,
  repr = "exp(x)",
  df = Exp,
  type = "exp",
  inverse = Log
)

is_exp = function(x) x%@%"type" == "exp"

Sendo estrito, a definição de inversa de monômios que dei só vale para domínio nos positivos, mas este é o tipo de sofisticação que ainda não resolverei nesta série de posts. Testando pra ver se está tudo funcionando corretamente:

f = Const(3)
f(5)
#> [1] 3
D(f)
#> x -> 0
D(f, 2)
#> x -> 0

f = Mono(0.5, 2)
f(3)
#> [1] 4.5
D(f)
#> x -> 1*x^1
D(f, 2)
#> x -> 1

f = Log
f(exp(1))
#> [1] 1
D(f)
#> x -> 1*x^-1
D(f, 2)
#> x -> -1*x^-2

f = Exp
f(1)
#> [1] 2.718282
D(f)
#> x -> exp(x)
D(f, 2)
#> x -> exp(x)

Até agora conseguimos definir algumas funções elementares, mas ainda não podemos fazer nada muito divertido com elas. O cálculo começa a ficar interessante quando podemos definir novas funções através de somas, produtos e, com destaque especial, composições. No próximo post da série explicarei como adicionar isto ao sistema. Até lá!

Parte 2/4: Definindo somas, produtos e composições
Parte 3/4: Ensinando as simplificações álgebricas
Parte 4/4: Tornando a representação das funções mais inteligente

O código como encontrado ao final deste post pode ser visto aqui.

lurodrigo’s blog

Sobre uma pequena conexão entre anagramas e números primos

Um pouquinho de terminologia da álgebra

E o que isso tem a ver com anagramas?

Mas tanta linguagem nova pra quê?

Uma introdução ao Shiny e reatividade

A estrutura de um aplicativo Shiny

Estrutura da UI

Eventos vs Reatividade

Um primeiro exemplo de reatividade

Objetos de entrada e saída

Definindo o comportamento da aplicação

Um segundo exemplo de reatividade

Parando reações: isolate()

Condutores reativos: reactive()

Ações event-like: observe() e observeEvent()

Criando nossos próprios verbos no dplyr

Criando o verbo transform_where

Criando um mutate_where:

Partições e idiomas

Partições e relações de equivalência

Inteligibilidade mútua

Como eu consegui descobrir a localização dos meus matches no Tinder (ou quase)

A ideia

A formulação matemática do problema

A coleta dos dados

A solução numérica

O resultado final

Try it yourself!

Writing a simple symbolic computation system using R (Part 2/4)

Defining sums and products

Defining compositions

New functions

Escrevendo um pequeno sistema de computação simbólica em R (Parte 2/4)

Definindo soma e produto

Definindo composições

Novas funções

Writing a simple symbolic computation system using R (Part 1/4)

Escrevendo um pequeno sistema de computação simbólica em R (Parte 1/4)

Criando o verbo `transform_where`

Criando um `mutate_where`: