Jump to content

sam88

Membro Inativo
  • Posts

    158
  • Joined

  • Last visited

2 Followers

Recent Profile Visitors

1,841 profile views

sam88's Achievements

Collaborator

Collaborator (7/14)

  • Very Popular Rare
  • Reacting Well Rare
  • Dedicated Rare
  • First Post
  • Collaborator

Recent Badges

133

Reputation

  1. Justo, reparei depois que testei. Vi o código e eu usava algo parecido, e que também não funciona mais. Well, enquanto não acho outra api gratuita, vou ter de baixar no manual. rsrsrs Mas valeu mesmo assim, gostei de ver que essa linguagem nim é bem veloz por manter uma saída bem parecida com C.
  2. massa, hein! To usando esse porque não implementei algo no meu programa. Vou usar esse seu por conta da portabilidade. Compilei pra Linux (Xubuntu 20.04) e funciona muito bem. Obrigado!
  3. Entendo, o ruim no meu caso é que eu trabalho com software (programação), dai já tenho tendencia a achar que posso automatizar tudo rsrsrs, mas já tinha pensado nessa ideia de usar mais a intuição. Vou dar um tempo novamente pra ver o que fazer, se bem que loteria tá mais como hobby do que profissão pra mim. Valeu ai.
  4. Na verdade eu quis dizer que uso os sorteios passados de forma aleatória, tipo pego um numero entre 500 e 1200 que será usado do sorteio 1 até esse número como treinamento do programa e ai deixo o resto para predição. EU tava procurando colocar esses 5 grupos como dz fixas, mas pelo que vi é bem baixo o retorno. Acho que vou ver se consigo aumentar pra 10 dz e ver se acerta pelo menos 8 com a mesma porcentagem. Mesmo assim, obrigado ai pelos comentários.
  5. Corrigi aqui, parece que não é 100%, mas apenas 62.5%. Só não sei como aproveitar isso, mas 62% é bem alto pra uma predição.
  6. Olá pessoas, criei um preditor pra lotofácil que me dá a seguinte garantia: -dentre as 25 dz, ele me mostra 5 grupos de 5 dz onde saem exatamente 5pts num desses grupos. Testei aqui com sorteios aleatórios e acreditem, é previsível acertar 5dz de 15. É muito mais fácil acertar 5 dz das 15 do que acertar um jogo de 15 que sai >=11 pts. Algum proveito pra isso? Vim perguntar por ideias, ainda estou trabalhando no programa. Quem quiser postar ideias, fique a vontade. NOTA: -só lembrando que pode ser bug pois é muito recente tal preditor.
  7. Isso, sou eu. Entendo, nesse caso não posso usar porque esse meu código faz parte de uma aplicação comercial. Vou deixar com a lookup table enquanto não acho uma solução melhor. Mas obrigado ai pelos exclarecimentos e ao @Omesmo também.
  8. Minha dúvida é se é portável, será que numa máquina amd vai ter suporte a essa função? Vou testar só mais tarde, agora vou sair. Faz sentido, por isso o aumento na velocidade.
  9. @Omesmo Testei aqui com std::popcount (e seu equivalente __builtin_popcount) e não teve diferença significativa com a lookup table. @rockcavera Não sei se tu testou exatamente do mesmo jeito que fiz. Mas deixa eu explicar pra tu testar ai se quiser: -a lookup table que falo é apenas uma tabela de 256 valores (8 bits cada) u_char table[256] //variável global ou estática na função -dai eu inicio ela com as quantidades de bits 1 em cada um dos 256 valores, ex: table[1] = 1 bit table[7] = 3 bits etc -para contar eu pego a uint64_t combA & combB e salvo em uint64_t combC -como combC é um tipo de 64 bits (uint64_t), eu uso um for assim: for (; c; c = c >> 8 ) //desloco 8 bits a cada iteração até que não haja mais nenhum valor em c -então, dentro do for eu só faço algo como: contador += table[c & 0xFF] Dai é instantaneamente somado os bits 1 atuais que já estavam previamente configurado. No máximo 8 iterações (se usar mais números), na lotofácil fica como apenas 4 iterações quando tem a dz 25 Tentei com uma table de 256*256 mas ficou muito lento. A mais rápida foi de 256.
  10. Justamente o que eu faço. Mas pensando melhor, adicionei uma lookup table e ai, excluindo o carregamento em memória, agora meu programa compara uma combinação de 15 contra as 3.2M em apenas 28 ms, mais de dez vezes menos que antes. Com uma lookup table, não preciso ficar contando todos os bits, basta pular de 8 em 8 bits e tá tudo contado. Valeu a ideia.
  11. E como que tu conta os bits iguais? Não me refiro a operação bit a bit AND. Ainda desconheço um jeito de saber quantos bits 1 são iguais sem que se use um for. Ali eu me referia a ter de usar um for pra ir movendo os bis e ir contando o que é 1 num inteiro a parte do resultado da operação bit a bit and.
  12. Como é feito essa contagem? Por exemplo: considere a combinação com csn 1, obviamente, deve-se contar da 2 em diante e comparar quais tem >=11 números iguais a combinação de csn 1. Agora, porque a que tem csn 3003 tem 346.126 combinações >=11? É comparado com tipo, de 3004 indo até 3.2 milhões, ou considera também as 3002 anteriores e faz a comparação também?
  13. SIm uso C++. Esses 6.619 milissegundos é para comparar uma única combinação contra as 3.2 milhões? Se sim, calculei aqui e meu programa leva 0.320 segundos (320 milissegundos) pra fazer o mesmo.
  14. Usando duas threads o que antes levaria tipo 10 segundos num programa normal, passa a levar 2 segundos. É uma grande otimização. Eu ainda estou aprendendo aplicar nos meus programas, mas basicamente é dividir as iterações de for e while em funções que processam cada parte em paralelo. Por exemplo: se tu quer conferir uma única combinação contra todas as 3.2 milhões da LF, tu usando threads faz algo como: thread_1 processa do 1 ao 1.6 milhões thread_2 processa do 1.6 milhões até a 3.2 milhões. Dai fica como se fossem dois programas num só, porém, cada thread executa em paralelo em núcleos do processador diferente, e por isso o grande aumento de velocidade de processamento. Não uso Delphi, mas nesse teu processador ai, deve dá pra usar umas 4 ou 8 threads por programa.
×
×
  • Create New...