Erros, bugs, perguntas - página 739

Novo comentário
 
ivandurak:

Optimizar por campos de bits, não haverá passagens desnecessárias nesta variante.

Por exemplo:

input int bp=0;
int a=0;
int b=0;
Start()
{
 switch(bp)
   {
    case 0: a=0; b=0; break;
    case 1: a=0; b=1; break;
    case 2: a=1; b=0; break;
    default: a=1; b=1; break;    
   }
}

e optimizar em determinados parâmetros, para este exemplo bp é optimizado de 0 a 3

 
ivandurak:
Só que se esqueceu de escrever o veredicto, quer possa ou não.
Não me esqueci de nada :) Se eu soubesse exactamente como fazê-lo, ter-vos-ia dito. É um pouco presunçoso dar um veredicto negativo, porque não conhecer a solução não significa que não haja solução.
 
Percebo a ideia. Pergunto-me se a genética enlouquecerá com um tal truque. Acontece que, em princípio, um conjunto de parâmetros de trabalho dá resultado zero e não está envolvido em mais selecção. É melhor nos desejos dos methaqvoters escrever algo como parâmetros optimizáveis relacionados, se for falso, então não deve ser anulado.
 
Yedelkin:

Como pode ser "mais fácil"? :) As condições para apagar uma EA ou para REASON_INITFAILED ainda têm de ser seguidas. Isto é o que parece ser um incómodo.

Se não houver uma solução elegante, pode usar primeiro a que é "mais fácil". Encontre algo melhor, pode sempre substituí-lo. :)
 
ivandurak:
Acontece que, em princípio, um conjunto de parâmetros de trabalho produz resultados zero e não está envolvido em mais selecção.
Nem por isso, se estamos a falar da minha ideia tortuosa. Com "conjunto de parâmetros de trabalho" e o primeiro passe trpar2=falso dará um resultado bastante funcional. Todos os passes subsequentes com o mesmo "conjunto de parâmetros de trabalho" e trpar2=false retornarão imediatamente zero, mas o seu "conjunto de parâmetros de trabalho" participará na selecção de qualquer forma e os passes duplicados serão rejeitados. Era isto que queria, não era?
 
tol64:
Na ausência de uma solução elegante, pode utilizar primeiro a solução "mais fácil". Se algo melhor for encontrado, pode sempre ser substituído. :)
Mais uma vez: o incómodo não é o comando para terminar o passe mais cedo - é uma solução bastante primitiva, seja ela qual for. Incómodo - em condições de rastreio para a conclusão antecipada da passagem. Pelo facto de a passagem ser completada antes do tempo com a ajuda da sua proposta, o "bloco de rastreio" em si não é reduzido, e a elegância deste bloco não é de modo algum aumentada.
 
Yedelkin:
Nem por isso, se estás a falar da minha ideia tortuosa. Com "conjunto de parâmetros de trabalho" e primeiro trpar2=falso, o passe dará um resultado bastante funcional. Todos os outros passes com o mesmo "conjunto de parâmetros de trabalho" e trpar2=falso conduzirão imediatamente a zeros, mas o seu "conjunto de parâmetros de trabalho" participará na selecção de qualquer forma. Era isto que queria, não era?

Pode corrigi-lo um pouco. Os parâmetros de optimização devem ser escritos nas estruturas, e eles (estruturas simples) devem ser tratados como variáveis. O código deve ser lido

if(!trpar && Par1===Parold1 && Par2===Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aqui Par e Parold são estruturas nas quais são escritos parâmetros óptimos de outros pares de moedas. Tantos pares como os "se", não parece tão feio. Obrigado.

 
Yedelkin:
Mais uma vez: não se trata de saber qual a ordem para terminar o passe mais cedo - esta é uma solução bastante primitiva, seja ela qual for. O incómodo está em manter um registo das condições para completar o passe mais cedo. O facto de que a passagem será completada antecipadamente com a ajuda da sua sugestão, "unidade de rastreio" em si não é menos incómoda, e a elegância desta unidade não é de modo algum aumentada.

Então, o que quis dizer com isso? Que, na ausência de uma solução elegante, não deve utilizar nenhuma? Mesmo que exista um, mas, como diz, "doloroso"?

Em suma, passemos à frente. Caso contrário, é mais incómodo devido às inundações do que devido ao código. :)

 
ivandurak:

Pode corrigi-lo um pouco. Os parâmetros de optimização devem ser escritos em estruturas, e eles (estruturas simples) devem ser tratados como variáveis. O código deve ser lido

if(!trpar && Par1===Parold1 && Par2===Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aqui Par e Parold são estruturas nas quais são escritos parâmetros óptimos de outros pares de moedas.

Sim, algo do género. Acontece que teremos de nos lembrar de TODOS os "conjuntos de parâmetros de trabalho" que colidiram com trpar2=falso. Isto é, o conjunto de estruturas correspondentes expandir-se-ia imensamente. Além disso, terá de ser guardado em ficheiro para ser lido memorizado em novo passe.
 
ivandurak:

Pode corrigi-lo um pouco. Os parâmetros de optimização devem ser escritos nas estruturas, e eles (estruturas simples) devem ser tratados como variáveis. O código deve ser lido

if(!trpar && Par1===Parold1 && Par2===Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aqui Par e Parold são estruturas nas quais são escritos parâmetros óptimos de outros pares de moedas. Tantos pares como os "se", não parece tão feio. Obrigado.

Há mais uma variante (escapou-me a ideia).

Pode dar uma vista de olhos às funções: OnTesterInit(), OnTesterPass(), OnTesterDeinit().

E FrameFirst (),FrameFilter (),FrameNext (),FrameInputs (),FrameAdd().

É exactamente para isso que servem. :)

Ou seja, pode sempre solicitar todos os parâmetros de qualquer passagem na optimização actual em qualquer altura.

1...732733734735736737738739740741742743744745746...3184
Novo comentário