Dia da apreciação

O ramo de trabalho mais democrático que conheço é o do varejo. Não é preciso ter grandes habilidades para conseguir um emprego num supermercado e as oportunidades são enormes. É possível começar limpando o chão e dez anos mais tarde estar gerindo uma loja com dezenas de funcionários.

Por isso, não me surpreendeu que ocorra no varejo uma prática muito interessante: o dia da apreciação. Nesse dia, as pessoas que trabalham no escritório vão para a loja e fazem o trabalho pesado do dia-a-dia. Nesse dia, a pessoa que achava que o trabalho de recepção de mercadorias era fácil descobre que é um trabalho sujo, pesado e muito cansativo. Nesse dia, as pessoas do escritório, que podem passar dias comunicando-se apenas por email, descobrem que é muito difícil interagir com dezenas de clientes todos os dias, mesmo que se esteja apenas organizando frutas.

Tenho visto alguns casos de falta de apreciação por parte de usuários nada compreensivos, assim como tenho tido dificuldade para compreender por que os usuários fazem certas coisas. Então, creio que seria no benefício de todos os setores de TI ter um dia da apreciação. E ele pode ser dividido em dois. No primeiro, os analistas e programadores visitam seus clientes: os usuários. No segundo, os usuários visitam o setor de TI e lhes é explicado tudo o que envolve criar e administrar os sistemas de apoio ao negócio.

Os usuários não vão entender os detalhes, mas isso não importa. Basta que tenham uma visão geral sobre como as coisas estão interligadas e sobre como há milhares de pequenos detalhes que interferem no cotidiano.

Por outro lado, os trabalhadores de TI vão entender melhor o que os clientes precisam. Analistas trabalham bastante com seus usuários, mas dificilmente ocupam seus postos e, por isso, estão limitados à capacidade de comunicação e síntese dos clientes.

Não pode haver forma mais simples e barata de melhorar a compreensão do negócio e de integrar as pessoas dentro de uma empresa.

Estamos nos libertando do hábito que tínhamos de explicar tudo

Na fria manhã de segunda-feira passei por um tapume que havia sido decorado com as palavras do título. Não costumo dar atenção a essas filosofias pontuais, mas tomei gosto por essa frase.

Deve ser por causa dos livros que tenho lido: Incompletude (sobre o trabalho de Gödel) e Metamat (de Chaitin). E hoje é o nonagésimo oitavo aniversário de Turing.

O autor dessa intervenção urbana deve ser um matemático rebelde. Na próxima, sugiro que ele escreva o seguinte:

Certas coisas nunca saberemos

A lei de Benford

Muitos conjuntos de dados apresentam uma propriedade interessante: os primeiros dígitos não aparecem todos com a mesma freqüência.

A lei de Benford prevê que os dígitos mais baixos apareçam com maior freqüência.

Esta lei funciona especialmente bem com números que crescem exponencialmente como preços e salários. O crescimento exponencial torna os dígitos mais altos mais raros, porque eles somem rapidamente. Se um produto tem um preço inicial 100, ele vai ficar valendo entre 100 e 199 o dobro do tempo que ficará valendo entre 200 e 299. Isto porque a inflação e os juros são cumulativos e, portanto, crescem exponencialmente.

Então, armado com este novo conhecimento, decidi avaliar minha base de preços.

select
 substr(preco, 1, 1),
 trunc((count(1)/29528)*100,2)
from produtos
group by substr(preco, 1, 1)
order by 2 desc

Em primeiro lugar, contei os registros para simplificar a consulta e fazer o cálculo mais rapidamente. Já dá para deduzir que tenho 29.528 registros. Os dados são do mundo real; eu não gerei números aleatoriamente.

A tabela abaixo mostra a distribuição dos primeiros dígitos:

Dígito	F	Fe
1	33,65%	30,1%
2	17,49%	17,6%
3	12,93%	12,5%
4	9,49%	9,7%
5	8,71%	7,9%
6	6,26%	6,7%
7	4,83%	5,8%
8	3,9%	5,1%
9	2,7%	4,6%

F é a freqüência encontrada e F_e é a freqüência esperada. Como se pode ver, a previsão chegou muito perto da realidade.

Essa lei, além de ser curiosa, é útil para apontar dados problemáticos na contabilidade forense. Distribuições muito estranhas podem colocar em evidência tentativas de esconder maracutaias financeiras.

Hey Hey 16K

Já vi algumas músicas com referências a tecnologia, mas este é o primeiro que vejo dedicado aos micros de 8 bits e com BASIC na letra.


É um Flash de uns 2MB, então carrega rápido. Para ajudar a cantar, ele já vai mostrando a letra.

Divirta-se!

O coeficiente de Gini em SQL

O coeficiente de Gini é uma medida de desigualdade usado na economia para avaliar a distribuição de renda de diferentes sociedades.

Ele é um número entre 0 e 1, sendo 1 a desigualdade completa (uma única pessoa tem toda a riqueza) e 0 a igualdade total (todos ganham a mesma coisa). O número também é interpretado como a metade da diferença média normalizada. Ou seja, se a média é R$1.000 e o coeficiente de Gini for 0,6, então a diferença média entre rendas vai ser R$1.000*0,6*2=R$1.200. Ou seja, neste caso, a diferença média é maior que a média; esta seria uma sociedade bastante desigual. Países considerados avançados, como os da Escandinávia têm coeficientes entre 0,2 e 0,3. Países como Brasil, Uruguai, Estados Unidos e China, têm coeficientes entre 0,4 e 0,5. Atualmente, o país mais desigual do mundo é a Namíbia, com 0,707.

Na falta de dados sobre renda, usei uma lista de produtos. Mesmo assim, vou supor estar usando uma tabela PESSOAS com as seguintes colunas:

• ID - um identificador único para casa pessoa;
• SALARIO - o salário.

Usando a definição supracitada, escrevi o seguinte no Oracle:

select (diff/media)/2 from (
  select avg(abs(p1.salario-p2.salario)) diff
  from pessoas p1, pessoas p2
  where p1.id<>p2.id
),(
  select avg(salario) media
  from pessoas 
)

Temos dois cross-joins. O primeiro é terrível, porque multiplica todos os registros da tabela por ela mesma para calular as diferenças. Como eu tinha 14.354 registros, o cross-join resultante disso tinha 206.022.962 linhas. Nada bom. Se eu quisesse calcular o coeficiente de Gini do Brasil, teria que usar uma tabela de uns 190 milhões de registros e isso não ia funcionar. O segundo é inócuo, porque o último select produz apenas uma linha.

Por sorte, um economista chamado Angus Deanton encontrou uma maneira melhor de calcular isto. Na fórmula abaixo, N é o número total de indivíduos, u é a média dos rendimentos, X é o rendimento de cada um e P é a classificação de cada um (sendo 1 o mais rico e N o mais pobre).


Isso é muito mais eficiente, porque agora não é mais preciso comparar cada um a todos os demais.

A consulta resultante usa a função analítica ROW_NUMBER() para classificar os salários:

select ((n+1)/(n-1))-(2/(n*(n-1)*media))*sum(pc*salario) from (
  select salario, row_number() over (order by salario desc) pc
  from pessoas
), (
  select avg(salario) media, count(1) n
  from pessoas
) group by n, media

A tabela abaixo compara os resultados:

SELECT	Tempo	Resultado
1	67,94s	0,55617007994480478319584630635542608397
2	0,03s	0,5561700799448047831958463063554260839701

O segundo, além de ser 2.264 vezes mais rápido, ainda produziu mais duas casas de precisão que, por outro lado, não têm nenhuma utilidade.