una strategia di trading basata sulla teoria dell'onda di Elliott - pagina 46
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Grazie... Ho trovato il capitolo pertinente nel libro. A proposito, se qualcuno dovesse mai trovare un bug nel mio codice di qualsiasi grado di antichità, gli sarei grato se potesse punzecchiarmi... nel caso mi fosse sfuggito. :-)
PS: cercherò di fare meno domande. :-)
In generale, penso che queste sciocchezze di programmazione non siano degne di essere discusse in questo thread.
Sì, lo sono.
Perché non capisco la necessità di controllare if(size-2!=0) - questo è uno.
E anche se ricordo vagamente di aver usato stime di campionamento e non voglio discutere fortemente contro disper=disper/(size-2) (invece di disper=disper/(size)) Sono sicuro che non ha senso affilare la forumula (cioè non c'è differenza tra i due in questo caso) - sono due.
Non sono un matematico, ma mi sembra che con una dimensione che tende all'infinito la varianza tenderà a 0... Quindi, se state stimando un campione di 400 barre, se ne sottraete 1 o 2, o non sottraete proprio nulla, il risultato finale non sarà molto influenzato... Tuttavia, la formula è una formula, e se mio zio ha scritto "N-2" in un libro intelligente, allora personalmente sono incline a seguire il suo consiglio... :-)
In linea di principio, naturalmente, questa condizione è completamente inutile.
L'ho appena fatto quando ho scritto il codice in origine - ho rimosso il controllo prima della divisione, poiché 0 non può essere perché il campione è ovviamente più grande. Ma poi, con lo sviluppo del codice, gli errori di divisione per zero hanno cominciato a verificarsi di tanto in tanto. Allo stesso tempo, dato che non c'è un debugger in MT4, era difficile scoprire dove si era verificato questo zero. E finché non ho verificato la condizione di controllare la divisione per zero in tutte le divisioni, non sono riuscito a capire esattamente in quale divisione è stato trovato lo zero! Beh, in futuro, ovviamente, potrete rimuovere questo controllo extra. Anche se dubito che darà un guadagno in tempo di calcolo, perché il tempo di base è speso nel calcolo stesso, ma non in alcuni controlli superflui della stabilità del codice.
Non c'è alcuna differenza fondamentale in queste formule per il nostro problema ed è improbabile che il profitto finale sia influenzato in modo evidente. Ma perché non fare tutto nel pieno rispetto di come dovrebbe essere secondo la matematica? Noi del sistema Vladislava stiamo solo cercando di allontanarci dalla soggettività e di ottenere la valutazione più oggettiva della situazione attuale del mercato basata su metodi matematici.
Hai ragione! Ma solo nella prima parte della tua dichiarazione ;o)))
Così, ora potete vedere chiaramente la differenza - se impostate il primo parametro su true, otterrete le ottave secondo il vecchio algoritmo, cioè usando le funzioni integrate per cercare gli estremi.
Se lo impostate su false (impostazione predefinita), otterrete, IMHO, ciò di cui avete bisogno. La differenza è la seguente. Gli estremi sono definiti per la definizione del campione - il massimo alto e il minimo più basso in una data area. Questo assicura che abbiamo una probabilità minima di catturare una parte dell'over trend. Viene poi confrontato con il valore più alto/basso delle ultime barre - che è solo su un lato del range dato - se siamo in un trend possiamo facilmente sfondare i livelli impostati e dovremo ricostruire le ottave in tempo.
Buona fortuna e buone tendenze.
HZZ c'è stato un errore - ho riscritto il codice - ora la differenza non è così evidente :).
И хотя я смутно вспоминаю использование оценок по выборке и не буду сильно спорить против disper=disper/(size-2) (вместо disper=disper/(size)) , уверен, что нет смысла затачивать форумулу(то есть, разницы между ними нет в данном случае) - это два.
In linea di principio, naturalmente, questa condizione è completamente inutile.
Quando stavo scrivendo il codice, in origine ho fatto così - ho rimosso il controllo prima della divisione, perché 0 non può essere perché il campione è ovviamente più grande. Ma poi, con lo sviluppo del codice, gli errori di divisione per zero hanno cominciato a verificarsi di tanto in tanto. Allo stesso tempo, dato che non c'è un debugger in MT4, era difficile scoprire dove si era verificato questo zero. E finché non ho verificato la condizione di controllare la divisione per zero in tutte le divisioni, non sono riuscito a capire esattamente in quale divisione è stato trovato lo zero! Beh, in futuro, ovviamente, potrete rimuovere questo controllo extra. Anche se dubito che darà un guadagno in tempo di calcolo, perché il tempo di base è speso nel calcolo stesso, ma non in alcuni controlli superflui della stabilità del codice.
Non c'è alcuna differenza fondamentale in queste formule per il nostro problema ed è improbabile che il profitto finale sia influenzato in modo evidente. Ma perché non fare tutto nel pieno rispetto di come dovrebbe essere secondo la matematica? Noi del sistema Vladislava stiamo solo cercando di allontanarci dalla soggettività e di ottenere la valutazione più oggettiva della situazione attuale del mercato basata su metodi matematici.
In realtà, non c'è alcuna differenza, poiché l'errore è trascurabile, ma ognuno può, ovviamente, contare a modo suo.
Infatti, ora possiamo vedere la differenza nella performance dell'indicatore.
Grazie mille per il miglioramento! Ora la frase "tutti i livelli sono normalizzati al timeframe giornaliero" ha probabilmente ricevuto la sua piena attuazione nell'indicatore finalizzato.
per favore, vedete come è corretta questa situazione? USDCAD H4, offset 40.
https://c.mql5.com/mql4/forum/2006/06/new_indicator.zip
Puoi vedere come il prezzo è andato una cifra e mezza sotto la linea dell'indicatore più basso. Non dovrebbe essere così?
https://c.mql5.com/mql4/forum/2006/06/new_indicator.zip
Puoi vedere che il prezzo si è spostato di una cifra e mezza sotto la linea dell'indicatore più basso. Non dovrebbe essere così?
No, non dovrebbe. Scusa - c'era un errore lì - il risultato di un refuso - quando si confronta con il bordo destro della gamma. L'ho corretto. Ora le differenze non sono così evidenti :). Lì invece del numero di barra dell'estremo alto per alto ha preso il numero di barra dell'estremo basso. L'ho scoperto quando ho iniziato a correre attraverso la storia in dettaglio.
Riorganizzerò i codici.
Buona fortuna e buone tendenze.
ZS riattaccato.