No seguimento deste post, relembro o exemplo que dei do jornal Público: http://www.publico.clix.pt/Sociedade/divulgacao-de-escutas-na-internet-punivel-pela-lei-do-cibercrime_1419063. Acho que é claro para todos que não existe, no site do jornal Público, nenhum directório “Sociedade” e muito menos um directório para cada notícia que eles colocam.

Na realidade, o que acontece é um redireccionamento invisível do pedido para um script central que, neste caso, trata das notícias. Esse redireccionamento é feito com a extensão mod_rewrite do Apache. O mod_rewrite é uma espécie de pau para toda a obra dos redireccionamentos, desde visíveis a invisíveis, com inúmeras aplicações.

Já devem ter reparado, em centenas de sites por essa ‘Net fora – aqui no DreamsInCode, por exemplo – em endereços cujo caminho é semelhante ao título da página; nalguns casos, inclui mesmo categorias. O caso em que me baseei foi o do site do jornal Público, por ter exactamente a característica que eu queria, e que o WordPress não tem. Se repararem neste URL, por exemplo, http://www.publico.clix.pt/Sociedade/divulgacao-de-escutas-na-internet-punivel-pela-lei-do-cibercrime_1419063, verificam que os caracteres acentuados constam do mesmo, o que não acontece com o WordPress, por exemplo.

Posto isto, o problema tem duas fases: converter os títulos ou os nomes dos registos para uma versão compatível com URL’s e depois redireccionar os novos URL’s para os scripts correspondentes ao tratamento do pedido. No entanto, converter os títulos, que parecia tarefa simples, foi, na verdade, bastante complicado; para isso contribuiu a codificação dos registos na base de dados, que está em UTF-8 (e se não tiverem em UTF-8, deviam ter).

Quem der uma vista de olhos por código meu, em especial em situações onde é necessária alta velocidade de execução – como no caso dos Jogos de Loto – encontrará, várias vezes, duas instruções que dão imenso jeito, unsafe e fixed.

A instrução unsafe é a mais simples e serve para marcar uma zona de código como não segura. Isto serve imensos propósitos, em particular o nosso amigo fixed.

Mas antes de irmos à explicação do fixed, é preciso explicar porque é que precisamos dele quando a velocidade de execução é fundamental.

As linguagens .NET são linguagens de compilação JIT (Just In Time), o que quer dizer que o código em que são feitas (C#, VB.NET, F#, etc.) são assembladas para um formato intermédio (CIL – Common Intermediate Language), que forma os executáveis e librarias normais (exe e dll). Ao serem executadas, o compilador JIT – inserido na máquina virtual, que é a framework .NET, de instalação obrigatória – transforma esse formato intermédio na linguagem máquina mais apropriada para o ambiente (sistema operativo, especificações de hardware) em que está a correr.

A máquina virtual .NET (e, na realidade, todas as máquinas virtuais, desde o Java até ao Flash Player) têm também um mecanismo chamado garbage colection (GC) (recolha de lixo, na tradução literal). O GC foi uma excelente ideia, quando apareceu pela primeira vez em 1959 (John McCarthy): retira das mãos do programador a responsabilidade de eliminar objectos, variáveis e ponteiros que já não estão em uso. Quem vem dum background em C ou C++ conhece bem o sintoma de se usar um ponteiro para uma área de memória vazia ou com dados inválidos (normalmente, segmentation fault e respectivo core dump; na pior das hipóteses, crash do sistema). Hoje em dia, já começa a ser difícil encontrar linguagens sem GC (com a honrosa excepção do C++ não-.NET) o que é, em quase todas as circunstâncias, óptimo!

Para além das funções discutidas aqui e aqui, a classe estática CombTools ainda contém mais algumas funções para manipular combinações ou conjuntos de combinações. Relembro, mais uma vez, que a classe é estática (assim como todos os seus métodos).

Os métodos são os seguintes:

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

Em primeiro lugar, o que é o CSN? O CSN é o Número Sequencial Combinatório (Combinatorial Sequence Number) de uma dada combinação, quando estas se encontram ordenadas lexicograficamente, isto é, tendo como exemplo C(50,5), da [1, 2, 3, 4, 5] até à [46, 47, 48, 49, 50]. Neste caso, os CSN’s seriam o 1 e o 2.118.760.

Uma forma de calcular os CSN’s, e vice-versa, seria simplesmente construir todo o desdobramento até ao CSN pretendido, ou até à chave pretendida. Don’t. É estúpido, é um desperdício de ciclos de processamento e é péssima programação. Sobretudo, se já alguém pensou no assunto e se os algoritmos são do domínio público. Mesmo que não saibam, pesquisem antes de cometer uma barbaridade deste tamanho.

Vamos então aos ditos…

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):

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