Errori, bug, domande - pagina 739

Nuovo commento
 
ivandurak:

Ottimizzare per campi di bit, non ci saranno passaggi inutili in questa variante.

Per esempio:

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 ottimizzare in determinati parametri, per questo esempio bp è ottimizzato da 0 a 3

 
ivandurak:
Solo tu hai dimenticato di scrivere il verdetto se puoi o non puoi.
Non ho dimenticato nulla :) Se sapessi esattamente come fare la cosa giusta, te l'avrei detto. È un po' presuntuoso dare un giudizio negativo, perché non sapere la soluzione non significa che non ci sia una soluzione.
 
Ho capito l'idea. Mi chiedo se la genetica impazzirà per un tale trucco. Si scopre che in linea di principio un set di parametri funzionante dà un risultato nullo e non è coinvolto in un'ulteriore selezione. Imho meglio nei desideri di methaqvoters scrivere qualcosa come parametri ottimizzabili correlati, se è falso, allora non dovrebbe essere sovrascritto.
 
Yedelkin:

Come può essere "più facile"? :) Le condizioni per cancellare un EA o per REASON_INITFAILED devono ancora essere tracciate. Questo è quello che sembra una seccatura.

Se non c'è una soluzione elegante, si può usare prima quella più "facile". Trova qualcosa di meglio, puoi sempre sostituirlo. :)
 
ivandurak:
Si scopre che, in linea di principio, un set di parametri funzionante produce zero risultati e non è coinvolto in un'ulteriore selezione.
Non proprio, se parliamo della mia idea tortuosa. Con "set di parametri di lavoro" e il primo passaggio trpar2=false darà un risultato abbastanza funzionante. Tutti i passaggi successivi con lo stesso "set di parametri di lavoro" e trpar2=false restituiranno immediatamente zero, ma il vostro "set di parametri di lavoro" parteciperà comunque alla selezione e i passaggi duplicati saranno respinti. Questo è quello che volevi, vero?
 
tol64:
In assenza di una soluzione elegante, si può usare prima quella più "facile". Se si trova qualcosa di meglio, può sempre essere sostituito. :)
Ancora una volta: il problema non è quale comando per finire il passaggio in anticipo - è una soluzione abbastanza primitiva, qualunque essa sia. Botherness - nel tracciare le condizioni per il completamento anticipato del passaggio. Dal fatto che il passaggio sarà completato in anticipo con l'aiuto della vostra proposta, il "blocco di tracciamento" non è diminuito, e l'eleganza di questo blocco non è aumentata in alcun modo.
 
Yedelkin:
Non proprio, se stai parlando della mia idea tortuosa. Con "set di parametri funzionante" e primo trpar2=falso il passaggio darà un risultato abbastanza funzionante. Tutti gli altri passaggi con lo stesso "set di parametri di lavoro" e trpar2=false porteranno immediatamente a degli zeri, ma il vostro "set di parametri di lavoro" parteciperà comunque alla selezione. Questo è quello che volevi, vero?

Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute. Per quante coppie ci sono se, non sembra così brutto. Grazie.

 
Yedelkin:
Ancora una volta: la seccatura non riguarda quale comando per terminare il passaggio in anticipo - questa è una soluzione piuttosto primitiva, qualunque essa sia. La seccatura sta nel tenere traccia delle condizioni per completare il passaggio in anticipo. Il fatto che il passaggio sarà completato in anticipo con l'aiuto del tuo suggerimento, "l'unità di tracciamento" in sé non è meno fastidioso e l'eleganza di questa unità non è aumentata in alcun modo.

Cosa intendeva dire con questo? Che in assenza di una soluzione elegante, non si dovrebbe usarne affatto? Anche se ce n'è uno, ma, come dice lei, "doloroso"?

In breve, andiamo avanti. Altrimenti è più fastidioso dall'allagamento che dal codice. :)

 
ivandurak:

Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute.

Sì, qualcosa del genere. Si scopre solo che dovremo ricordare TUTTI gli "insiemi di parametri di lavoro" che si sono scontrati con trpar2=false. Cioè l'insieme delle strutture corrispondenti si espanderebbe immensamente. Inoltre dovrà essere salvato in un file per leggerlo ricordato al nuovo passaggio.
 
ivandurak:

Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute. Per quante coppie ci sono se, non sembra così brutto. Grazie.

C'è un'altra variante (mi è sfuggita).

Potete dare un'occhiata alle funzioni: OnTesterInit(), OnTesterPass(), OnTesterDeinit().

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

È esattamente a questo che servono. :)

Cioè, potete sempre richiedere tutti i parametri di qualsiasi passaggio nell'ottimizzazione corrente in qualsiasi momento.

1...732733734735736737738739740741742743744745746...3184
Nuovo commento