Confronto tra la media mobile (e qualsiasi altro indicatore) e l'errore - pagina 4
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 per il consiglio, naturalmente, ma posso leggere l'Aiuto da solo. E ripeto che la matematica computazionale non è legata a un particolare linguaggio di programmazione. Sono solo gli errori di calcolo con cui ho a che fare, con i quali si passa.
Se non solo potete leggere l'Aiuto, ma anche capirlo, allora state facendo demagogia deliberata, continuando ostinatamente a parlare di normalizzazione e delle sue potenziali applicazioni con uno spirito sminuente. Compresa la demagogia deliberata sui pericoli della sua applicazione.
E non sto facendo il furbo, ma dando dei controesempi (anche per la tua amata normalizzazione).
La demagogia era lì. Non ci sono stati controesempi sulla normalizzazione.
A parte il fatto che qualcuno può applicarlo male.
Quindi gli epsilon possono essere applicati in modo errato. Sì e la demagogia è già stata menzionata.
P./S.: Il post è sulla normalizzazione, quindi non menziono le medie mobili.
E penso che Artem possa aiutarvi meglio con gli EAs che usano le MAs di quanto possa fare io con quelli difficili.
Cerca i crossover ad ogni tick. Qual è il problema?
Non è mai necessario normalizzare nulla quando si confrontano due numeri reali.
Se i numeri sono davvero uguali, sono immagazzinati in memoria allo stesso modo. In realtà, è proprio grazie a questa proprietà che le macchine di calcolo possono esistere.
Quindi, i confronti della forma if(a<b) o if(a==b) sono corretti in ogni caso e non è richiesta alcuna normalizzazione.
Se la mente curiosa di un ricercatore trova contraddizioni a questa regola, significa che o la sua macchina è fuori uso, o la sua mente. Uno dei due.
L'aiuto e la documentazione naturalmente dovrebbero essere letti almeno qualche volta (sono stati scritti anche da umanoidi come noi), ma è necessario avere il proprio ragionamento sensato.
Se non solo potete leggere l'Aiuto, ma anche capirlo, allora state facendo demagogia deliberata, continuando ostinatamente a parlare di normalizzazione e delle sue potenziali applicazioni con uno spirito sminuente. Compresa la demagogia deliberata sui pericoli della sua applicazione.
La demagogia era lì. Non ci sono stati controesempi sulla normalizzazione.
Senza contare il fatto che qualcuno potrebbe non usarlo correttamente.
Quindi gli epsilon possono essere applicati in modo errato. E la demagogia è già stata menzionata.
Ci sono stati dei controesempi (almeno in termini di normalizzazione anche della differenza, come qui espresso). Lo dirò di nuovo: la normalizzazione è il modo più semplice per coloro che non vogliono scavare nelle complessità. Ha letto la documentazione e crede piamente a tutto. Di nuovo, ripeto che il linguaggio di programmazione all'interno della matematica computazionale è irrilevante. Se è scritto così nella guida, non significa che sia vero (altrimenti non ci sarebbero problemi di matematica computazionale e di epsilon che ti piacciono tanto). C'è molto scritto anche sul recinto, ma questo non significa che sia la verità in ultima istanza. Se sei contento dell'opzione Halp, hai tutto il diritto di esserlo. Ma è una scelta personale. E non significa che risolva tutti i problemi che ho cercato di chiarire qui. E considerare come demagogia qualcosa che semplicemente non si vuole capire (di nuovo, il vostro diritto), non significa che sia demagogia stessa. Non sto facendo domande retoriche sul senso della vita (le cui risposte sono solo demagogia), sto solo cercando di capire qualcosa che non ho ancora incontrato. Di nuovo, diciamo che i valori sono sempre gli stessi ogni volta che li calcolate. Lì si potrebbe ottenere qualcosa dalla stessa matematica computazionale. Ma quando anche i valori sono diversi, non sarà possibile trovare un algoritmo universale, anche se sei un mega-guru.
Inoltre, voglio solo assicurarmi che la mia comprensione del fatto che se un robot non lavora per tick, ottenere intersezioni multiple all'interno di una barra è praticamente impossibile. Può già essere attribuito puramente alla complessità di mql.
P.S. Non sto cercando di discutere con qualcuno senza motivo, non penso di essere sempre un genio giusto. Non mi piace quando la gente cerca di essere intelligente e scrive qualcosa senza nemmeno leggerlo. Non ha niente a che fare con te personalmente. Grazie per il vostro aiuto e i vostri pensieri sull'argomento. Ma ancora, IMHO è sbagliato scrivere qualcosa sulla pazienza quando si insiste su un solo punto di vista nella documentazione (in cui si crede con tutto il cuore e non si accettano opinioni ed esempi alternativi), e gli epsilon non sono di vostro gradimento. Spero che Artyom capisca anche quello che ho scritto nel post scriptum prima di questo. Grazie a tutti per le vostre risposte e scusate se sono diventato un po' permaloso da qualche parte.
P.P.S. La normalizzazione a una certa cifra decimale è infatti analoga all'introduzione dell'epsilon solo per l'ordine dello stesso segno.
P.P.P.S. Se abbiamo una discussione così accesa, sarei molto grato se condividete le vostre esperienze in questo argomento, perché risposte adeguate (soprattutto sul 2 e 3 elementi che mi preoccupano), infatti, non ha ottenuto. Anche se setacciando molti forum, quasi arrivato alla conclusione che, sì, 2 punto è impossibile. Gli sviluppatori di mql potrebbero pensare a questo, e fornire più flessibilità, perché è molto scomodo (in qualsiasi altro linguaggio di programmazione ha la possibilità di cambiare dinamicamente l'interfaccia del programma, e qui si scopre che non c'è nessuno ((())
Ci sono stati dei controesempi (almeno in termini di normalizzazione anche della differenza, come espresso qui). Lo dirò di nuovo: la normalizzazione è il modo più semplice per coloro che non vogliono scavare nelle complessità. Ha letto la documentazione e crede piamente a tutto. Di nuovo, ripeto che il linguaggio di programmazione all'interno della matematica computazionale è irrilevante. Se è scritto così nella guida, non significa che sia vero (altrimenti non ci sarebbero problemi di matematica computazionale e di epsilon che ti piacciono tanto). C'è molto scritto anche sul recinto, ma questo non significa che sia la verità in ultima istanza. Se sei contento dell'opzione Halp, hai tutto il diritto di esserlo. Ma è una scelta personale. E non significa che risolva tutti i problemi che ho cercato di chiarire qui. E considerare come demagogia qualcosa che semplicemente non si vuole capire (di nuovo, il vostro diritto), non significa che sia demagogia stessa. Non sto facendo domande retoriche sul senso della vita (le cui risposte sono solo demagogia), sto solo cercando di capire qualcosa che non ho ancora incontrato. Di nuovo, diciamo che i valori sono sempre gli stessi ogni volta che li calcolate. Lì si potrebbe ottenere qualcosa dalla stessa matematica computazionale. Ma quando anche i valori sono diversi, non sarà possibile trovare un algoritmo universale, anche se sei un mega-guru.
Inoltre, voglio solo assicurarmi che la mia comprensione che se un robot non lavora per tick, ottenere intersezioni multiple all'interno di una barra è praticamente impossibile. Può già essere attribuito puramente alla complessità di mql.
P.S. Non sto cercando di discutere con qualcuno senza motivo, non penso di essere sempre un genio giusto. Non mi piace quando la gente cerca di essere intelligente e scrive qualcosa senza nemmeno leggerlo. Non ha niente a che fare con te personalmente. Grazie per il vostro aiuto e i vostri pensieri sull'argomento. Ma ancora, IMHO è sbagliato scrivere qualcosa sulla pazienza quando si insiste su un solo punto di vista nella documentazione (in cui si crede con tutto il cuore e non si accettano opinioni ed esempi alternativi), e gli epsilon non sono di vostro gradimento. Spero che Artyom capisca anche quello che ho scritto nel post scriptum prima di questo. Grazie a tutti per le vostre risposte e scusatemi se sono diventato un po' permaloso da qualche parte.
P.P.S. La normalizzazione a una certa cifra decimale è infatti analoga all'introduzione dell'epsilon solo per l'ordine dello stesso segno.
P.P.P.S. Se abbiamo una discussione così accesa, sarei molto grato se condividete le vostre esperienze in questo argomento, perché risposte adeguate (soprattutto sul 2 e 3 elementi che mi preoccupano), infatti, non ha ottenuto. Anche se setacciando molti forum, quasi arrivato alla conclusione che, sì, 2 punto è impossibile. Gli sviluppatori di mql avrebbero potuto pensare a questo, e fornire più flessibilità, perché è molto scomodo (in qualsiasi altro linguaggio di programmazione ha la possibilità di cambiare dinamicamente l'interfaccia del programma, e qui si scopre che non c'è nessuno ((())
Per me usare la conversione dei dati usando la funzione NormalizeDouble quando si confrontano i doppi è uno dei due modi, stipulati nella documentazione, per far funzionare le condizioni del programma esattamente dove e come era previsto quando si scrivono condizioni specifiche nel codice. Questo è quello di cui parlavo prima. Di conseguenza, non è solo l'eliminazione di eventuali errori. Sono anche vari modi ponderati di trasformare i dati per soddisfare qualsiasi condizione.
Te l'ho detto e te lo sto dicendo, basandomi sulla mia personale esperienza pratica nel linguaggio di programmazione che stai iniziando a imparare. Per questo motivo, e suggerito più volte in questo thread, di utilizzare un modo così pratico.
A proposito, dirò, in parte, d'accordo con voi, che non contesterò che la normalizzazione con questa funzione può essere il modo più semplice per qualsiasi compito in termini di trasformazione di dati di tipo reale
Ma sta a ciascuno decidere quale dei due metodi raccomandati nella Documentazione usare quando si convertono dati di tipi reali.
E la scelta di uno di questi modi non è determinante per sapere se uno è il tipo di persona che cerca di capire le sottigliezze necessarie o no.
Che non mi piacciono gli epsilon non era una parola da parte mia. Non applicare alcun metodo non è necessariamente amore/disprezzo. Né ho insistito nell'applicare solo il secondo modo dei due.
Le mie parole letterali in termini di applicazione pratica delle peculiarità di lavorare con numeri di tipo doppio, che:
P./S.: Si dà il caso che il primo metodo di Documentazione si è rivelato meno conveniente per me da usare, anche in base ai compiti che, di regola, risolvo da solo. Di conseguenza non ho molta esperienza con il primo modo.
Ma quando si applica il secondo modo (cioè confrontando la differenza normalizzata di due numeri reali con il valore zero nell'espressione dell'operatore condizionale), non è emerso alcun problema in modo univoco.
Ma se ho fatto un confronto di numeri non normalizzati (qui intendo, senza usare anche il primo modo), allora sì, è stato che ho trovato un funzionamento errato delle condizioni sulla base di confronti di numeri di tipo doppio.
Inoltre, ho anche dato un tale chiarimento:
P./S.: Detto questo, nel caso, chiarirò ancora una volta, che confrontare i numeri reali con il primo metodo dei due elencati qui ,confrontando la differenza di numeri con qualche piccolo valore, non posso chiamare peggio che usare la normalizzazione, quando è necessario regolare il livello di confronto (incl., poiché per me il secondo metodo era più conveniente, non ho considerato per me più dettagliato per l'applicazione pratica).
Cioè, in termini di normalizzazione quando si convertono dati di tipo doppio, non avevo bisogno del primo modo. In particolare, a causa della convenienza per me di usare la funzione NormalizeDouble nella risoluzione di vari problemi (e non solo nei confronti).
Questo sito ha un'enorme base di conoscenza accumulata.
Le persone hanno risolto e stanno risolvendo tutti i tipi di compiti di diversa complessità utilizzando MQL4.
Dopo che MQL4 è stato avvicinato a MQL5, le possibilità del primo sono aumentate ancora di più.
Penso che dovreste conoscere meglio questo linguaggio di programmazione e non ignorare la base di conoscenza accumulata sui siti qui. Acquisire esperienza pratica nel suo utilizzo. E solo allora potrete dire qualcosa di sicuro in termini di applicazioni in questo linguaggio di programmazione e delle sue capacità.
Ho un ToR diverso) E ancora, ho già scritto dei problemi con le zecche. Non c'è modo di spiegare al cliente perché il robot è entrato nel trade se non vede il crossover sul grafico
Prendi i valori di MA sullo zero e sulla prima barra di ogni tick - allora e solo allora puoi trovare gli incroci di MA sulla barra zero. Li prendi dalla prima barra al momento dell'apertura della barra zero - e lì i valori MA sono quelli che erano presenti quando la prima barra è stata chiusa, non quando si è formata. Semplicemente leggi i valori di МАšek in ritardo e quindi non li vedi incrociare. La normalizzazione non c'entra niente. E a proposito, se le AM mostrano valori di prezzo, allora i valori dovrebbero essere normalizzati a _Digit, invece di indovinare a quale valore la normalizzazione è necessaria...
Cari partecipanti al forum. Si prega di non stabilire battibecchi sul forum. Solo sull'argomento del thread.
Penso che l'argomento possa essere chiuso. Gli autori (non l'argomento) delle dichiarazioni non hanno raggiunto un consenso. Ci sono stati momenti isolati di sciovinismo, il che non è gradito.
Ma né l'uno né l'altro sono stati in grado di provare il loro caso. Ecco perché chiudo il thread. Ulteriori discussioni possono essere punite (divieto massimo giornaliero).
Anche se se ci sarà data una prova normale, è benvenuta.
I giudici saremo io e Volodya.
Questa non è una discussione.
Non ho visto tutto questo qui, quindi non so quali argomentazioni sono state fatte all'interno del topic. Ma poiché suppongo che si tratti di dimostrare la mia posizione, che è simile a quella di Artem in questo post (e prima qui nel thread), darò uno degli esempi qui sotto, in relazione al fatto che la normalizzazione debba essere applicata in un modo o nell'altro quando si lavora con numeri di tipo reale.
Con screenshot e una variante del codice di prova.
Artyom ha scritto nel post sopra:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
E dato che anch'io credo (come penso che facciano molti altri) che questo sia un modo semplice ed efficace nelle direzioni più comuni dei problemi, farò solo questa piccola aggiunta di mio:
con quante cifre decimali è concepito per visualizzare la linea MA, o semplicemente eseguito calcoli basati su qualsiasi numero di cifre decimali (lo stesso confronto), con tante cifre decimali e normalizzazione (arrotondamento a una certa cifra decimale).
/*Per alcuni compiti individuali, ci possono essere delle "eccezioni", e si può variare per ottenere il risultato desiderato, per esempio, confrontando un valore con una cifra decimale inferiore, con un valore con una cifra decimale superiore. Ma se questo è necessario per il compito in questione, allora a mio parere può essere ben consigliato, se necessario, come con il metodo di cui sopra, stampare i valori ottenuti e confrontare i valori ottenuti con la resa visualizzata sul grafico.
Se abbiamo bisogno di emettere valori di tipo doppio come testo (attraverso Print, Comment, OBJ_LABEL ecc.), allora dovremmo usare DoubleToString poiché vogliamo convertire il numero in testo.
Ora, dalla spiegazione introduttiva alla chiarezza:
Negli screenshot:
I dati dello script di test sono valori MA ottenuti utilizzando la funzione iMA (con e senza trasformazioni utilizzando le funzioni descritte per lavorare con tipi reali nella Documentazione).
Si può vedere nella finestra dei dati e sul grafico che le linee con un posto decimale inferiore hanno pareggiato i valori sulla terza barra, senza contare quella attuale, del grafico. Si può anche vedere che i valori MA dal set standard al terminale, disegnati sui decimali del grafico, non sono uguali e visivamente si sono equalizzati sul grafico un po' prima.
Cioè, se ingrandisci gli screenshot o fai i tuoi esperimenti usando lo script di prova allegato o i tuoi codici, vedrai che le linee MA, con il numero di decimali come nel grafico, si incrociano un po' prima.
Ed è comprensibile. Per analogia, le linee con decimali sono uno in meno delle linee disegnate con citazioni a due cifre su un grafico a tre cifre. Permette di vederli in "vecchi" punti del tempo in cui le quotazioni a tre o cinque cifre nei terminali non sono molto diffuse e, allo stesso tempo, hanno i vantaggi delle quotazioni decimali estese per il trading (compresi gli spread più stretti).
Cioè, le linee basate su valori con meno cifre decimali hanno meno "rumore".
Ma se l'arrotondamento non fosse applicato (in questo caso, usando la funzione di normalizzazione), un numero chiaramente limitato a una specifica posizione decimale sarebbe più problematico.
O, se solo in numeri:
123.4561 e 123.4556 non sono uguali. E la loro differenza non è zero.
Tuttavia, se li arrotondate per eccesso, sia il primo che il secondo numero, saranno uguali ed equivalenti a 123,456. Di conseguenza, la differenza tra loro sarà 0.
Sta al decimale arrotondare i valori risultanti, a seconda dei compiti da svolgere.
Nelle schermate del diario "Esperti", si possono vedere i valori MA in uscita usando iMA con le conversioni descritte nella Documentazione, e senza conversioni dei valori risultanti. Le impostazioni di MA nello script di test sono uguali a quelle degli indicatori sul grafico.
Nel secondo screenshot, potete vedere i delta tra due valori di MA con e senza trasformazioni.Qui sotto, come ho detto, c'è un piccolo codice di prova. Non è ottimizzato, ma permette di fare vari esperimenti con i valori di MA, compreso il cambiamento di alcuni parametri.
Il numero di barre in esso è impostato in questa linea:
P./S.: Ho sostituito lo script di prova allegato. Ho sbagliato variante nel mio post. Sbagliato. Mi dispiace.
Gli screenshot precedentemente allegati non sono necessari, quindi li lascio lo stesso.