
Os três pontos fundamentais da minha posição são os seguintes:

### 1. Os sorteios são aleatórios.

Penso que ninguém poderá colocar em causa esta afirmação, sob
pena de ensandecer rapidamente. Ou acreditamos que os sorteios não são, de alguma forma,
manipulados, ou deixamos, pura e simplesmente, de jogar (e de sair à rua também, com medo dos
homens de negro ou, pelo menos, com medo do ministro Santos Silva);

### 2. Prever os X números sorteados é impossível

Ponto final. Cada sorteio é independente e
aleatório e, como em todos os acontecimentos aleatórios, não tem memória dos acontecimentos
passados. É **perfeitamente possível** sair a mesma chave duas semanas consecutivas,
[tal como aconteceu recentemente na Bulgária](http://news.bbc.co.uk/2/hi/8259801.stm) (foi
ordenada uma investigação, que entretanto já concluiu que não houve fraude);

### 3. A única maneira de garantir um dado prémio é esgotando o respectivo espaço combinatórico.

Isto é, para garantir em absoluto um 6 no totoloto é necessário jogar com as 13.983.816 chaves.

Esta minha visão centra-se no conceito probabilístico das totolotarias; penso que não seja
surpresa para nenhum apostador, regular ou não, que a _house edge_ das totolotarias é brutal. No
entanto, o estudo estatístico de qualquer acontecimento aleatório, e de totolotarias em
particular, mostra-nos algumas características que podemos fazer jogar a nosso favor. Por exemplo,
estatísticamente, qualquer acontecimento aleatório tende para o equilíbrio. É fácil fazer esta
verificação com um dado, ou com uma moeda: se se lançar uma quantidade elevada de vezes, cada uma
das faces terá saído, sensivelmente, em igual número.

É preciso nunca esquecer que as aberrações estatísticas, como o já citado caso da Bulgária, são
probabilisticamente possíveis. A probabilidade de sair uma chave _X_ depois de uma chave _Y_ é
sempre igual, mesmo quando _X = Y_. Estatísticamente, essa chave fica em _supervit_ de saídas mas,
probabilisticamente, não aconteceu nada de extraordinário.

Jogar em totolotarias, duma forma consistente, é uma questão de equilíbrio entre o que se pretende
gastar e os potenciais retornos. Como a única maneira de garantir absolutamente o primeiro prémio
é jogar com todo o espaço combinatório, o capital necessário para semelhante aposta ultrapassa,
normalmente, o retorno total. É neste momento que se abandona o estudo probabilístico e entra o
estudo estatístico. Eliminar números das apostas – tanto directamente, como através de filtros de
figuras de chave – é um imperativo. Quantos e quais, depende de cada pessoa e da sua sensibilidade
em relação às diversas estatísticas possíveis.

Revejam o meu ponto 2: prever os _X_ números sorteados é impossível. No entanto, encaixar esses
_X_ números sorteados num lote razoavelmente superior, é uma **possibilidade**. No ano passado,
terminei um estudo no [euromilhoes.com](http://www.euromilhoes.com/forum/showthread.php?t=7281)
(_link quebrado_), com 52 semanas de duração, de previsão de números. Durante esse ano, em lotes
entre 20 a 26 números (a média é de 22,4 números), prognostiquei várias vezes 5 e 4 acertos.
Sensivelmente a meio do ano, ao tentar fazer uma melhoria no meu programa que calculava os
prognósticos, introduzi um _bug_ que alterou a pontaria de forma brutal (basicamente, virei o
cálculo estatístico de trás para a frente, o que está errado, como é lógico). Só dei conta no
balanço final, mas a primeira metade do ano compensa largamente as perdas da segunda. Tenham a
noção que o programa era muito básico, assentando em apenas dois parâmetros, o atraso e a
quantidade de saídas de cada número. Introduzir outros parâmetros, nomeadamente figuras de chave,
poderia reduzir a quantidade de apostas necessária sem influenciar na mesma proporção o retorno.

Para já, é tudo, e deixo-vos com este conselho: joguem com moderação e nunca, nunca, joguem acima
das vossas possibilidades!



A forma habitual de calcular combinações, que nos ensinaram na escola, é a seguinte:

$$
C_k^n = \frac{n!}{k! \times (n - k)}
$$

No entanto, calcular desta forma numa aplicação informática levanta desde logo dois problemas:

1. A maior parte das linguagens de programação não tem uma função para calcular factoriais, embora
seja muito fácil fazer uma, simplística, é certo, de forma recursiva:

```clike
função factorial(n)
  devolve (n * factorial(n - 1));
fim de função factorial
```

2. Mesmo os mais modestos factoriais atingem rapidamente o limite dos tipos inteiros. Por exemplo,
usando `Int32`, o limite é 2.147.483.647, ou 4.294.967.295 (sem sinal); o reles $13!$ já rebenta
com qualquer um deles. OK, podíamos usar inteiros de 64 _bits_, afinal, quase todos os
processadores actuais são de 64 _bits_ (mas o sistema operativo também tem que ser, não se
esqueçam); ficávamos com limites de 9.223.372.036.854.780.000 ou 18.446.744.073.709.600.000 (sem
sinal). Pois, mas basta um $21!$ para ficarmos logo sem pé outra vez.

Posto isto, que fazer?

Desmontando a fórmula das combinações, poderíamos chegar a uma fórmula recursiva, e respectivo
algoritmo:

$$
\begin{aligned}
C_k^n = [(n - 0) / (k - 0)]
\newline
\times [(n - 1) / (k - 1)]
\newline
\times \dots
\newline
\times ([n - (k - 1)] / [k - (k - 1)])
\end{aligned}
$$

```clike
função numeroDeCombinacoes(n, k, dif)
  se (dif = k - 1) então:
    devolve ((n - dif) / (k - dif));
  senão:
    devolve (((n - dif) / (k - dif)) * numeroDeCombinacoes(n, k, dif - 1));
fim de função numeroDeCombinacoes
```

As funções recursivas, porém, não são lá muito amigas da performance… mesmo com _tail optimization_
(que este exemplo nem tem). Para alguns factoriais mais _musculados_, esta função cedo ia
arrastar-se nos cálculos.

O algoritmo que vou apresentar de seguida foi publicado em 1963 (não, não é gralha, é mesmo
seis-três) por **M. L. Wolfson** e **H. V. Wright**.

```clike
função numeroDeCombinacoes(n, k)
  seja dif = n - k;

  se (k < dif) então:
    seja dif = k;
    seja k = n - dif;

  seja combinações = k + 1;

  se (dif = 0) então:
    seja combinações = 1;
  senão: se (dif >= 2) então:
    para (i = 2; i <= dif; i = i + 1)
      seja combinações = (combinações * (k + i)) / i;
    fim de para;

  devolve combinações;
fim de função numeroDeCombinacoes
```

Reparem como ainda podemos reconhecer a fórmula explicada acima neste formato não recursivo.
É maravilhosamente elegante e (ainda) é o algoritmo mais rápido para se calcular o número de
combinações.
