Este post é uma reedição de um post meu no euromilhoes.com.

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

formula_combinacoes

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:
    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 inteiros em linguagens strongly typed (isto é, quase todas as linguagens desktop, e mesmo algumas web). 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?

Finalmente, tive um tempinho para acabar a secção de projectos, que é onde irão parar todos os downloads relacionados com… well, projectos, não é verdade? Para já, estão apenas dois activos, o projecto Jogos de Loto e o projecto SisRed Series.

Para inaugurar a coisa, disponibilizo já o SisRedEM v2, projecto que transita do euromilhoes.com para aqui. Não se esqueçam que, para efectuar os downloads, é preciso estarem registados aqui. No caso em concreto do SisRedEM v2, devem ter, também, registo no euromilhoes.com.

Hoje, ao longo do dia, é provável que disponibilize mais coisas, no Jogos de Loto, nomeadamente alguns algoritmos que disponibilizei no passado no euromilhoes.com.

Esta meta era a principal responsável por 95 dias de intervalo blogueiro – daqui para a frente é esperada maior regularidade.

Comentários Nenhum comentário Continuar a ler Continuar a ler »

Este post é uma reedição de um post meu no euromilhoes.com.

Antes de se avançar para qualquer estudo estatístico em totolotarias, é conveniente termos a noção de qual é a probabilidade de acertarmos com um dado conjunto de números. Só assim é possível aferir a fiabilidade de um conjunto de filtros, ou uma metodologia de escolha de números e/ou filtros, por via da sua aplicação ao historial do concurso. É claro para toda a gente que, se uma dada metodologia tem resultados inferiores ou sensivelmente iguais à probabilidade natural dum conjunto de números de igual tamanho, essa metodologia está desafinada ou é uma treta (ou ambas).

Por esse motivo, fiz este estudo em Novembro de 2006 para o Euromilhões (números e estrelas) e para o totoloto. A primeira coluna das tabelas é a quantidade de números escolhida e a primeira fila é a quantidade de acertos. Nas tabelas onde essa primeira fila é 1, 2, 3, etc., a probabilidade é calculada para exactamente esses acertos, nem mais, nem menos; Nas tabelas onde a primeira fila é 1+, 2+, 3+, etc., a probabilidade é calculada para pelo menos esses acertos (1 ou mais, 2 ou mais, etc.).

Ver-me-ão falar muito sobre jogos de loto (euromilhões, totoloto, etc.) por aqui, pelo que é conveniente terem a noção da minha posição base sobre os mesmos.

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 (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.

Num site em que página sim, página não vai ter código, é necessária uma forma de o apresentar convenientemente: com o espaçamento correcto, colorido, preferencialmente diferenciado por linguagem, e, já agora, com mais alguns extras, como a numeração das linhas.

A questão do espaçamento é facilmente resolvida envolvendo o código em tags <pre> </pre>. No entanto, dando de barato a questão das cores do código por enquanto, existe um problema muito maior: o espaçamento é mesmo respeitado! Se não colocarem nenhuma quebra de linha  - e a maior parte do código tem linhas bastante compridas – a caixa de código correspondente vai crescer por ali fora… E nem vale a pena fixar a largura das <pre> por CSS: o código vai simplesmente saltar fora da caixa!

Como é habitual, o Google eventualmente devolveu a solução a este problema, via blog do Tyler Longren (e uma adenda do Markku Laine). Os estilos necessários para forçar as quebras de linha dentro das <pre> é complexo, porque nem todos os browsers aceitam da mesma maneira (que surpresa…) e, precisamente por causa disso, a CSS não é standard compliant. A solução não me agradava nem um bocadinho, mas ainda a usei… durante um dia. Seja como for, porque pode dar jeito a alguém, cá vai (com os comentários traduzidos para português):

O webdeveloper que se preze enfia com o Google Analytics em tudo o que desenvolve; às vezes porque dá jeito, outras por questão de hábito. O que é certo, é que dá mil a zero ao AWStats (embora o AWStats, como corre na própria máquina que está a analisar, dê estatísticas de coisas que o Analytics não consegue – embora haja mais maneiras do gato ir ás filhozes).

Uma das coisas que sempre me fez espécie, é o facto do Google servir o Analytics descomprimido! E isto é mau por vários motivos:

  1. Apesar do script, hoje em dia, estar quase sempre morno por ser usado tantas vezes, volta e meia lá calha visitarmos uma página nova ou, sobretudo os webdevelopers, com a cache limpa – quando isso acontece, pega lá 24 kB. Podem dizer que 24 kB, hoje em dia, não é nada, mas…
  2. Mas esses 24 kB nem sempre vêm mal se chama! O lado mau do script ser tão conspícuo hoje em dia, é que os servidores do Google não têm mãos a medir para o servir a todos quanto o chamam e/ou os saltos que temos de dar até ao servidor estão entupidos. Não é incomum ver-se uma página bloqueada durante mais de 4 segundos à espera do Analytics, o que me leva ao terceiro ponto;
  3. A maneira recomendada pelo Google de se inserir o script deve ser a pior prática de sempre, via document.write(). Como se já não bastasse a tag <script> bloquear a página, a própria instrução que a insere, document.write(), também bloqueia! No dia em que, por qualquer motivo, o script teimar em não vir, temos uma página a carregar para toda a eternidade. Já é a pensar nisso que é recomendada a inserção imediatamente antes do </body>, mas, seja como for, não é agradável ver a página em carregamento durante tanto tempo.

Agora que já bati que chegue, vamos à solução, se é que ainda não deu para perceber pelo título do tópico: alojar o script na mesma máquina do site.

Pequena colecção de perguntas que, com toda a certeza, mais cedo ou mais tarde me irão colocar. Esta lista não é estática, por isso convém passar por cá de vez em quando.

Se o facto do post ser fixo não vos diz nada, cá vai: é fortemente aconselhado lerem isto antes de se registarem, para depois não terem surpresas. Não tem nada que não apliquem no vosso dia-a-dia, mas leiam, apesar de tudo.

Siga…

Bem-vindos ao blog do DreamsInCode!

Este blog servirá de apoio ao resto do site, onde poderão encontrar explicações e exemplos sobre as outras áreas e onde poderão deixar o vosso comentário, as vossas dúvidas e as vossas críticas. Servirá também como rampa de lançamento, isto é, antes de qualquer coisa aparecer nas outras áreas, será, certamente, abordada aqui inicialmente.

Os principais temas que aqui serão abordados têm direito a um ícone específico, e são os seguintes:

Quando me decidi a fazer este espaço, incluíndo um blog, tive um dilema durante para aí dez segundos: faço eu um motor de blog, ou uso um dos disponíveis?

Volta e meia vejo por aí blogs de developers ou programadores que dizem à boca cheia, ah e tal, o blog foi feito por mim, não usei nenhum motor de blog ou CMS… Alguém tem demasiado tempo em mãos. Reparem que, se o blog for  única coisa do site, e se foi feito como proof of concept, até aceito; mas se for como integração num projecto mais vasto…

O bom programador é inerentemente um malandrão: código escreve-se uma vez e é reutilizável, e isto aplica-se não só ao nosso próprio código, mas a código livre de outros programadores, a menos que tudo o que encontremos, não sirva, de todo, os nossos interesses. Não é, claramente, o caso dos motores de blog, onde há motores para aí ao pontapé; as CMS’s são um caso diferente, onde nenhuma das existentes serve os meus interesses: ou tem funcionalidades a menos, ou tem funcionalidades a mais, ou tem mais buracos que um queijo suiço (e não me façam falar do Joomla).

Literalmente enquanto construía este espaço, atravessou-se-me ao caminho uma tecnologia social de que nunca tinha ouvido falar, em parte por eu sempre ter sido um autêntico bicho anti-(rede)-social. São os gravatars.

A palavra gravatar é uma abreviatura de globally recognized avatar e, como o próprio nome indica, é um avatar supostamente reconhecido pela ‘Net fora. Isto é, em vez de, por cada site, blog, fórum, etc., em que participemos, termos de carregar um avatar novo (ou, pior ainda, termos de nos sujeitar aos que existem disponíveis nas livrarias por defeito), lá está o nosso gravatar a acompanhar-nos…

 Categorias
 Arquivo
 Projectos em Destaque
 Últimas Postas no Blog
 Últimos Comentários do Blog