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
E puoi anche aggiungere il drawdown come percentuale, così è più facile da vedere. >> Grazie.
Questo può essere l'inizio di un convertitore da FSB a MQL4.
Qualsiasi aiuto o feedback è molto apprezzato.
Sarebbe bello se FSB potesse generare una DLL con la strategia e la funzione potesse assomigliare a questa:
cioè inviare un numero di barre alla DLL e ottenere una risposta dalla strategia
Il dll stesso è così
hai comunque tutti i tuoi indicatori e hai solo bisogno di dati di serie temporaliFornirò più tardi il ponte FSB <-> MT4 completo.
Quindi FSB prenderà le informazioni sulla quotazione e sul conto da MT e rimanderà indietro gli ordini di trading. In questo modo sarà in grado di negoziare le strategie FSB in MT.
Ora sto cercando di fare alcuni framework EA di base per inserire le strategie FSB in MT come EA senza alcun interop.
Ho bisogno di diversi modelli semplici come:
* Entrare (aggiungere, ridurre, chiudere) all'apertura della barra (o valore dell'indicatore) quando:
- condizione1 == vero; e
- condizione2 == vero; e
- condizione3 == vero; e
- condizione4 == vero
* Uscire alla chiusura del bar quando:
- condizione1 == vero; o
- condizione2 == vero;
o
* Uscire al valore dell'indicatore.
o
* Uscire allo stop loss permanente
o
* Invertire seguendo le regole di ingresso.
La maggior parte degli indicatori sono standard e gli altri sono piuttosto semplici e possono essere facilmente riscritti in MQL4. Una volta che abbiamo il modello EA di base non ci saranno problemi a tradurre gli indicatori.
Le cose che sto testando ora sono:
Aprire la posizione a "Bar Opening" e chiudere a "Bar closing".
Quindi spero di sviluppare due nuovi prodotti:
1. FSB - alimentazione dati MT e ponte di esecuzione
2. esportatore di strategie in MQL4
Probabilmente entrambi i programmi saranno open source.
(oh, pensavo che l'argomento fosse tranquillo ora... ravviviamolo :)? (Scriverò molto... cercherò di essere logico ;), e di non sovraccaricare l'argomento - lo dividerò in diversi messaggi)
Signori, benvenuti!
Miroslav - prima di tutto, un paio di parole "sul tempo" (la parte lirica)... (Spero sinceramente che la tua comprensione del russo sia all'altezza :))).
Il prodotto, ovviamente, è fantastico! Parlo per esperienza, sia come ex programmatore che come utente astratto (software astratto). Si può sentire l'amore per esso (perché tutto è fatto con molta attenzione) e c'è la speranza che lo sviluppo del programma non si fermi "improvvisamente" (non muoia). Sì, molto probabilmente ci sono alcuni errori logici (un esempio illustrativo era con Data Horizon), ci sono piccoli bug nell'interfaccia... Ma nel complesso - QUESTA È LA CANZONE! È solo una canzone!!!
Chiedo al pubblico di prestare attenzione ad un altro fatto rivelatore. L'atteggiamento verso la critica e lo stile di discussione di problemi/difetti/nuove caratteristiche/ecc. Questo sono io nel contesto dell'inizio del thread, dove è iniziato lo sviluppo del prodotto alternativo, e come l'autore della SSB ha reagito ai commenti fatti al suo indirizzo. Non credo che Miroslav abbia anche una "vagonata" di tempo per sviluppare un programma GRATUITO (e che sia un programmatore del genere). Ma trova il tempo per noi (per comunicare), secondo i nostri commenti e richieste per finalizzare il prodotto, corregge i bug e offre qualcosa di nuovo (vedi i suoi post recenti). E tutto è calmo, misurato, senza isterismi, come nel già citato caso delle SSB. Questo merita rispetto (extra). I miei saluti, Miroslav...
Per finire la parte lirica (ora astratta) - che personalmente sono un sostenitore della teoria del "movimento casuale dei prezzi". Cioè in questa domanda condivido completamente l'opinione di una certa cerchia di persone (compresi i creatori di siti come http://www.bigmany.ru), che sono convinti che lavorando nel mercato (intendo Forex e "tutto ciò che gli è vicino") dove non c'è modo di riconoscere il secondo dei (soli) due principali indicatori di mercato (intendo Volume). - è semplicemente inutile e senza senso (privo di qualsiasi senso ragionevole) fare affidamento su qualsiasi informazione dell'analisi tecnica e, in misura minore, fondamentale...
Avremmo potuto finire qui in generale :), ma come sapete - la Russia è nota per gli sciocchi e le strade, e utilizzando il primo punto di questa dichiarazione - ancora non lascio l'idea "per fare milioni" :D, infatti - sono solo curioso. È interessante ascoltare le "opinioni degli analisti" (come gli astrologi con i loro oroscopi - "molti specialisti", non molto utili), è interessante solo guardare i grafici (siete d'accordo - è incredibile), è interessante scavare nel codice (si comincia a capire davvero ciò che la gente cerca di esprimere con questo indicatore), ... È solo interessante... È interessante imbrogliare (o meglio ancora - NON imbrogliare) il "sistema" un giorno... Ecco perché sono qui (nel mercato, condizionatamente) e spero di beneficiare non solo me stesso, ma anche il pubblico. Perché come Miroslav - qualche altruista nella vita.
La mia opinione attuale è che i sistemi di analisi tecnica che sono attualmente utilizzati in tutto il mondo (e la netta maggioranza) sono in effetti, INVOLONTARI nel mercato. Cioè, la folla di persone, guardando i loro monitor e guidata dai valori dei loro indicatori, si aspetta amichevolmente il movimento in una certa direzione, fa accordi... e muove proprio quel prezzo. Anche se su piccola scala, anche se non sempre (ci sono ancora proprietari di "fabbriche, giornali, navi a vapore" che se ne fregano dell'AT, hanno solo bisogno di comprare o vendere un certo volume in un certo momento). Ma succede! In altre parole - essendo "nel giro" (della stessa AT), potete cercare di spostare la probabilità dei vostri movimenti casuali positivi nel mercato verso (leggermente?) più del 50%. Non è facile... MA possibile! Non appena sarò deluso da questo postulato - lascerò il mercato... (e non si tratta della dimensione dei profitti/perdite, è solo, beh, davvero frustrante e inutile lavorare in un sistema completamente casuale... beh, vedi sopra)
Quindi, ora passiamo agli affari.
1. Mentre qui c'è stata una pausa - ho pensato. Sì, possiamo aspettare Miroslav (quando farà un ponte tra MT e FSB, o qui, compilatore di strategie). Ma, alla fine - chi almeno fa qualcosa da solo ottiene il risultato :). Sono partito dal presupposto, che ho (garantito) un dato strumento (FSB), ho MT, supponiamo, che oltre a queste due entità non ci sarà altro - quindi operiamo nel loro quadro, cioè: FSB (al momento) è un sistema chiuso; avremo bisogno di MT in ogni caso; il codice del consulente (robot di trading) sarà necessario in ogni caso - sì, ci dovrebbe essere un modello universale, che (approssimativamente) dà valori di indicatori e tutto, quindi secondo "schema approvato"; quindi avremo bisogno di indicatori stessi.
2. Mi fermerò subito al codice Expert Advisor. Non condivido l'ottimismo dei creatori di semplici Expert Advisors - beh, è impossibile immaginare il numero di situazioni anomale nel terminale e nel mercato. E stiamo parlando di soldi, nessuna battuta è appropriata (non hanno controllato il codice di errore - hanno calcolato qualche azione predefinita... e questo è tutto, -$1000 è andato (condizionalmente)). Cioè, sono convinto che qualsiasi esperto che si occupa veramente di denaro (o, meglio, di denaro reale) deve essere "ferreo" in termini di reazioni agli eventi esterni. Il codice deve prevedere un numero massimo di variazioni nel funzionamento del terminale, del server o del mercato stesso. In breve - è abbastanza serio, e non può essere risolto (scritto) con un salto. Sarei felice di partecipare alla creazione di tali modelli. Ma...
3. Ho deciso di andare fino in fondo dal basso. Ho avuto un'idea - se non c'è niente con cui operare per un Expert Advisor (indicatori) - per cosa abbiamo bisogno di un Expert Advisor allora :)! Così ho preso gli indicatori.
La premessa era la seguente. Prima di tutto, nessuno garantisce che i valori degli indicatori nel FSB siano equivalenti ai valori degli indicatori standard o aggiuntivi nella MT. E per ottenere risultati "comparabili" in entrambi i programmi - i valori dovrebbero essere gli stessi. In secondo luogo, il numero di indicatori stessi (standard) è SEMPRE diverso. E per usare (e cercare) quelli esterni... in qualche modo mi piace o lo standard o il mio (nella vita)... (Terzo - ho l'impressione che la "conversione" del codice degli indicatori da FSB non è un compito così grande, come ha menzionato Miroslav - gli algoritmi stessi sono abbastanza semplici, gli indicatori stessi sono molto "organizzati" in termini di codice (il codice è unificato), cioè approssimativamente - creano un insieme di errori.Grosso modo, creiamo un modello una volta e lo "riempiamo" con alcuni indici uno per uno (questa è l'immagine ideale del mondo :))). C'è di più nella quarta - mi chiedevo :).
Comunque, il fine settimana è stato questo. Prima di iniziare qualcosa, di solito "prendo molto tempo per imbracare" (in questo caso - pensare). Non ho tempo per modificare il modello stesso (lo capisco). Soprattutto quando il numero di indicatori supera una certa cifra. Quindi i punti chiave dovrebbero essere progettati subito. Di conseguenza, ho fatto le seguenti ipotesi:
- Questi dovrebbero essere indicatori (e non solo funzioni per il futuro codice dell'Expert Advisor). Dopotutto, la percezione visiva delle informazioni non gioca il minimo ruolo per un umano (e per me, in particolare), e la chiamata di un indicatore dal codice di Expert Advisor non è un problema così grande (l'iCustom ha già causato un sacco di problemi sul forum - quando ci sono così tante opinioni, di solito preferisco controllare tutto da solo, i risultati delle mie "prove sul campo" faranno, c'è probabilmente un piccolo overhead, ma NON è un grande (questo lo dichiaro con piena responsabilità) e penso che possa essere trascurato in termini di universalità). Ma per gli "intenditori speciali" :) (non si sa mai) nel caso in cui i calcoli negli indicatori siano fatti in una funzione separata dello stesso tipo (vedi sotto).
- Gli indicatori devono emettere gli stessi valori del FSB originale (voce negoziata separatamente qui sotto). Cioè il codice di FSB viene preso come base e, se possibile, modificato il meno possibile.
- Il codice dovrebbe essere ottimizzato per funzionare correttamente con IndicatorCounted (cioè per velocità)
- I parametri indicatori, così come i loro valori devono essere uniformi e omogenei. Non sto parlando di tipi di dati, in quanto tali. Se guardate il codice degli indicatori di Miroslav, potete vedere una buona omogeneità dei parametri di ingresso e dei buffer di uscita. Il compito è quello di mantenere l'immagine iniziale per aiutare gli utenti ad essere facilmente guidati quando si indicano i parametri o si prendono i valori degli indicatori.
- L'implicazione del punto precedente è ... mm (attenzione - questo è importante). Il punto chiave dell'utilizzo di tutti gli indicatori non è che essi generino valori propri. È che producono SEGNALI! Davvero, per me come persona - che differenza fa quale sia il valore di un indice ora o dopo(?!) Si tratta sempre di "cifre incomprensibili". Comprensibile è quando si tratta di 'Comprare' o 'Vendere' :). Tutto il resto è "poco chiaro"! Miroslav ha usato questa idea in modo molto elegante creando due buffer in ogni indicatore (per le posizioni lunghe e corte) che, a seconda di come l'indicatore viene utilizzato (come punto della posizione o condizione logica), acquisiscono valori di apertura/chiusura di una posizione o del filtro Sì/No (se tutti sono "Sì" nella logica di apertura - aprire, se almeno un "No" nella logica di chiusura - chiudere (in generale, RTFM). Geniale! ;) Ho seguito questa strada e ho simulato questo comportamento. Al momento, i primi due buffer dell'indicatore (i cui valori possono essere visti nella Finestra Dati) sono i buffer corrispondenti con i filtri (1/0) o con i valori del prezzo per aprire posizioni al lato lungo o corto, rispettivamente. In seguito, quando si utilizzano gli indicatori nel codice dell'Expert Advisor, non gli importa molto cosa, dove o quali valori genera un particolare indicatore - si limiterà ad analizzare i valori dei primi due buffer per un argomento molto semplice (Sì/No (condizionalmente) o presa diretta del prezzo da lì) ... E questo è tutto! C'è una sfumatura - quasi il 100% di "inciampo" su Ishimoku (lì, la quantità di buffer dell'indicatore stesso è vicino al limite del MT stesso (8) - Non voglio rifiutare una bella idea (con i primi due buffer), ma non posso combinarli in uno (stavo pensando... ci potrebbe essere non solo 1/0 (che potrebbe essere trasformato in una bitmask), ma anche le etichette dei prezzi). Molto probabilmente dovrò fare qualcosa con i valori degli indicatori stessi... Vedremo... Come andiamo...
In generale, in breve (abstract): qualità (compatibilità FSB, bug-free, ecc.), facilità di ulteriore utilizzo, velocità, leggibilità del codice. In questo ordine.
Bene, e (in realtà) - cosa è successo ... (breve storia)
- Tutti gli indicatori hanno il valore "fsb" nel prefisso del nome del file (esempio: "fsbBlaBlaBla.mq4").
- Ho preso gli indicatori stessi in un ordine pseudo-casuale, quindi non biasimarmi. Finora c'è, cioè. Per ulteriori discussioni/analisi ecc. - Penso che sia abbastanza.
- Miroslav utilizza tre funzioni esterne (che si trovano nelle fonti (in fondo alla pagina)) per calcolare la media mobile e i valori dei buffer logici. Ho dovuto iniziare con loro. Tutte le funzioni sono racchiuse in un file (" fsbCommon.mq4 "), organizzato come funzioni di libreria (" fsbCommon.mqh "). C'è un altro file di quest'opera (" fsbConstants.mq4 "), che, rispettivamente, contiene costanti per comodità nel codice. Non ci sono stati problemi particolari con le funzioni stesse (ho un po' complicato la logica iniziale degli "oscillatori logici", per controlli aggiuntivi (array fuori limite, valori iniziali corretti garantiti (i primi nella storia) (Miroslav, c'è un errore logico nel codice su questo argomento).. .e ho cercato a lungo di "emulare" il comportamento di iShift in MovingAverage in modo che la funzione riempia correttamente i valori del buffer risultante per qualsiasi valore sano di questo parametro (e non solo per quelle restrizioni che sono date nel codice originale originale) ... di conseguenza, ho abbandonato questa faccenda per ora, mettendo uno "stub" all'inizio (con iShift diverso da "0" la funzione non lavoro ancora, che però non è stato ancora necessario). necessario) - alla fine è apparso un parametro aggiuntivo ( afTarget ) Inoltre, considerando IndicatorCounted (), un altro passaggio Il parametro è responsabile del valore della prima barra per l'elaborazione. Ebbene, l'ultimo parametro aggiuntivo imposta la "costante di prezzo" in termini di MT, dal valore di cui vengono calcolati i valori del MovingAverage stesso in base agli array di serie esistenti, o (se il valore iAppliedPrice al di fuori dei valori di "costanti di prezzo" MT) - basato su fonte . (da qui il sovraccarico del codice) Specifico subito la sfumatura della programmazione - dove ci sono cicli intervallati da selezioni caso per caso - i cicli sono inseriti all'interno delle selezioni, e non (cosa solitamente più logica) viceversa. Fatto non perché non so come farlo bene, ma perché so quanto velocemente :)! (beh, in futuro non mi dilungo su questo, chiunque voglia analizzare il codice - siete i benvenuti, ma prima di porre la domanda "sulla stupidità del codice" pensate un po' a cosa (potenzialmente) potrebbe causare tale programmazione).
Un'altra sfumatura è collegata a MovingAverage (potrebbe essere informativo per qualcuno) - perché. I valori della media mobile nelle modalità di livellamento esponenziale (incluso Smoothed) dipendono direttamente dai propri valori precedenti: la scelta del "punto di partenza" diventa molto importante (quale valore prendere come base per ulteriori calcoli). Di solito ci sono diversi approcci a questo. Qualcuno prende il prezzo di chiusura del periodo precedente. Qualcuno ha fatto la media del prezzo per il periodo precedente N... Miroslav ha fatto la seconda strada. MT viene chiaramente prima. Da qui le discrepanze significative in queste due modalità di smoothing all'inizio del grafico (ho aggiunto uno spazio vuoto per testare MovingAverage e tutto il resto (" fsbTest.mq4 "))! E le restrizioni da me imposte all'interno della funzione sulla disponibilità dei dati del MovingAverage stesso PRIMA iFirstBar o una quantità simile di valori calcolati DOPO iFirst Bar. Perché gli indicatori stessi utilizzano una costante per il valore minimo delle barre sul grafico (ora 2000) - questo dovrebbe essere sufficiente per qualsiasi situazione (perché non ho ancora visto parametri con periodi maggiori di 200). A meno che, ovviamente, non venga utilizzata più di una MA alla volta ;).
- Per analogia con il paragrafo precedente, sono stati creati file per sottofunzioni esterne che già utilizzo nel mio lavoro con questo progetto (prefisso "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")
- Bene, in realtà - gli indicatori stessi. In parole povere (prendendo ad esempio " Bar Range "):
slotType imposta genere slot in Termini FSB (punto della posizione o condizione logica) . Quegli indicatori che possono essere non solo filtri di entrata/uscita, ma anche impostare il prezzo di apertura/chiusura: questo parametro determina esattamente cosa genererà l'indicatore nei suoi buffer logici. Vedi tutte le costanti in fsbConstants.mq4 (tutto è abbastanza chiaro lì)
indLogic - infatti, una condizione logica per l'indicatore (porta un carico semantico diverso, a seconda del valore tipo di slot )
Bene, i parametri vanno oltre, nell'ordine in cui appaiono nelle fonti degli indicatori su forexsb.com e come vengono visualizzati nell'FSB stesso. I limiti dei parametri sono specificati nei commenti e sono controllati quando si chiama init() chiamando la sottofunzione PCheck().
Con i buffer, tutto a livello globale viene utilizzato come buffer dell'indicatore (allegato all'indicatore stesso). Solo quelli logici desiderati (LPIndBuffer[], SPIndBuffer[]) (sempre e sempre in questo ordine (#0 - posizioni lunghe, #1 - posizioni corte)), IndBuffer[] - dati dell'indicatore stesso. Ma in questo caso, poiché viene utilizzato un istogramma del colore, questo buffer contiene solo i valori stessi e due buffer aggiuntivi vengono utilizzati per la resa cromatica (ad essere onesti, MT ha iniziato a programmare solo trasferendo gli indicatori :), e come puoi simulare il comportamento degli istogrammi a colori all'interno di MT altrimenti - non l'ho mai inventato (chi può dirlo? Se questo è anche possibile)). Non vengono visualizzati in alcun modo in DataWindow.
A dentro() tutto è come al solito (vengono controllati i valori dei parametri, vengono impostati i nomi dell'indicatore stesso e gli indici, vengono allegati i buffer, ecc.)
In deinit() sto pensando di inserire la logica in caso di NON chiudere l'indicatore (ulteriore comodità, in modo che i parametri, lì, non vengano resettati, ecc.), a mio piacimento (non ancora una priorità).
inizio() molto primitivo. Il suo compito è verificare che ci siano abbastanza barre sul grafico (per calcolare qualsiasi MA e in generale) e chiamare la funzione per il calcolo dell'indicatore stesso, al momento della chiamata con successo viene chiamato il disegno personalizzato dell'indicatore (se necessario essere disegnato in qualche modo in un modo speciale, come in questo caso come -once)
Calcolare() - calcoli effettivi. Il codice, in generale, è simile al codice di Miroslav, vengono fatte eccezioni per le ottimizzazioni relative a IndicatorCounted(). Se sono necessari buffer indicatori aggiuntivi per calcolare l'indicatore, questi vengono impostati all'interno della funzione stessa (statica) (in modo da non sprecare gli indici dell'indicatore stesso) e sono serviti dalla funzione BufferSync(). Ecco una battuta separata: inizialmente c'era un tentativo di limitare i calcoli di un altro parametro costante (iMaxBars). "Prove sul campo" (parte 2) del comportamento degli array di serie in presenza di storia, assenza, movimento nel futuro (l'arrivo delle virgolette, l'aumento degli array a DESTRA (sono ora visivamente, sulla rappresentazione grafica )), ... movimento nel passato (quando manca la cronologia (ci spostiamo a sinistra sul grafico) e il terminale la carica dal server... e gli array si espandono a SINISTRA)... Quindi. .. Interruppe. L'ho fatto magnificamente (ho provato a farlo) - a seconda della direzione dell'espansione BufferSync () ed espande l'array risp. sinistra o destra, compilando i valori EMPTY_VALUE vuoti. Qui solo MT normalmente non espande gli array di indici a SINISTRA. Li espande SEMPRE a destra (dal lato di [0] Bar). Spero che sia chiaro di cosa sto parlando - che durante il prossimo salto indietro nella storia, quando il valore delle barre sul grafico supera iMaxBars (saltando, di nuovo) - sono possibili situazioni in cui l'indicatore non disegnerà i suoi valori a sinistra di iMaxBars, ma qui ci sono "dati strani" da esso, a sinistra di iMaxBars possono essere facilmente. Forse nessuno li guarderà... Ma "non belli" (non il nostro metodo). E tutto ciò che serve è che MT stesso integri i buffer con valori vuoti nella giusta direzione ... È potenzialmente possibile catturare una situazione del genere, ma ... In generale, attingiamo dall'inizio del grafico ... _sempre_. (Bene, per quanto possibile per questo particolare indicatore)
Un'altra sfumatura è associata a IndicatorCounted() - sembrerebbe - una funzione divina. Restituisci i valori delle barre calcolate e non ci saranno pretese nei tuoi confronti... SARÀ! Penso che la colpa non sia dell'IndicatorCounted() stesso (così come dei programmatori di MQ), ma di un gruppo di programmatori di indicatori personalizzati, che non hanno raggiunto lo scopo divino di questa funzione. Pertanto, è costretto a restituire sempre un piccolo numero di valori potenziali. O ricalcoliamo l'intero grafico (IndicatorCounted() == 0), o il primo ((IndicatorCounted() == Bars - 1) o due (IndicatorCounted() == Bars - 2). Quello che voglio dire è che, ad esempio, se la connessione è interrotta e il grafico "correva" più di una barra avanti - tutto qui ... "gli alberi sono morti in piedi" (IndicatorCounted() == 0) - contiamo l'intero grafico su un nuovo Perché? era impossibile restituire il numero di barre saltate (3, 4, ... 5... 10...)? (a cosa era destinata questa funzione, a quanto ho capito, inizialmente) In generale, in questo modo. ..
... Sono "inciampato" sulla RSI. E in tutti i sensi. In primo luogo, non ho capito il codice di Miroslav (le domande a lui andranno di seguito). In secondo luogo, durante il test dell'indicatore, ho visto discrepanze nei valori ottenuti all'interno di MT e FSB! No, non è affatto quello che pensavi ("sopportato storto" - beh, ammettilo, pensavi ;)). Il punto, purtroppo, sembra essere in queste dichiarazioni:
In breve - galleggia ! Dopo una piccola riflessione, per il momento ho rallentato. la primissima tesi (accuratezza e qualità) è diventata discutibile (ed è una priorità).
Qui è possibile il seguente ragionamento: da un lato, il float non è male, è, per così dire, un "irruvidimento" dei valori dell'indicatore, che dovrebbe rendere la strategia di trading ancora meno suscettibile ai picchi casuali del mercato. D'altra parte, ad esempio, quando si attraversa un certo fLevel (1.0, per esempio) - sarai d'accordo: 0.99998 e 1.00001 sono due grandi differenze :). E ci sono tali discrepanze. E se la posa si apre in un determinato momento, ma in realtà il livello FSB non raggiunge ancora 1.0 e scende, allora chi è la colpa? (quello che ha trasferito gli indicatori :D?!)
In realtà ci sono due soluzioni (dato che float MT non è supportato!):
- emula un float nella stessa MT (con alcune costruzioni strazianti come NormalizeDouble(X, Digits + 2) ) - beh, non ovunque, ma considera che ogni moltiplicazione / divisione per qualsiasi
- cambia il float in FSB in double. Qui devi capire la portata dei cambiamenti, ovviamente finiti, ma devi camminare con attenzione ovunque. E che il potenziale risultato delle strategie generate negli esseri umani può "fluttuare". E in generale, Miroslav ne ha bisogno? (la mia modesta opinione è che lo stesso FSB abbia bisogno di questo, perché la precisione extra non ha mai danneggiato nessuno, ma alla velocità dei calcoli (se questo obiettivo è stato perseguito (?), perché non vedo più ragioni) in questa sezione temporale della realtà Non dovrebbe avere alcun effetto significativo.) Sono d'accordo su questo problema con i ragazzi di MQ - perché. se non operiamo con la matematica intera (alcuni decimali), almeno proveremo con la massima precisione possibile. In generale, ecco una ... domanda non facile ...
Scusate la prolissità (non dirò altro, solo l'essenziale).
Mi piacerebbe sentire un parere - questo argomento dovrebbe essere continuato (e poi "andato" oltre, il resto degli indicatori da scavare)? Posso anche in un certo ordine (dal momento che tutto lo stesso il pasticcio originale :)), che, forse, ciò che deve andare avanti. Il tempo, purtroppo, nel caso generale è privato (vice direttore generale nel suo ufficio - "la giornata vola via inosservata" :D). Trovo il tempo di solito la sera, ma uno o due indicatori al giorno, penso di poter fornire...
Quindi, domande per Miroslav sull'argomento...
1. Qual è il valore di fMicron(l'ho impostato (di riflesso) a 0,000001, sembra, o è ancora meno?
2. Qual è il parametro bIsDescreteValues (nella logica dell'oscillatore). Ne capisco il significato - ma qual è il suo valore predefinito? E da quali condizioni dipende il cambiamento? (o dovremmo dire - a cosa è collegato (nell'interfaccia FSB o dove altro))
3. In realtà sulla RSI, cos'è questo disegno?
:)? La motivazione della domanda è la seguente: Se la mia visione è corretta - è un MA levigato. Nel contesto dell'intero codice - viene applicato al MA già calcolato e genera il MA lisciato, dove solo il primo valore rimane "vivo" :). Una specie di domanda logica - cosa c'è di superfluo qui? Questa costruzione, che tra l'altro rende REALIZZATA(!) la scelta dei modi di smoothing RSI nell'indicatore stesso (risulta sempre smoothed), così come nei suoi dipendenti. O calcoli MA precedenti (con modalità corretta dai parametri) per afPos, afNeg?
Chiaramente, l'RSI classico si basa sulla media frullata. Ma c'è almeno una variante con Simple MA e sarebbe logico rimuovere il codice di cui sopra rendendo operativo il comportamento del parametro maMethod. Oppure rimuoviamo il calcolo della MA prima di questo ciclo e rimuoviamo i parametri MA RSI in tutti gli indicatori (dato che non influenzano nulla comunque!).
Rimuoverei questo codice (sopra) :). (Nell'indicatore convertito questa parte è commentata, chi ha bisogno della funzionalità originale - rimuovere i tag di commento! Il codice RSI è solo per riferimento... Finché non decidiamo qui, lo userei "a mio rischio e pericolo" :))
4. Come già detto c'è un errore logico non critico nella logica degli oscillatori nel comportamento sulle barre iniziali. Ora non riesco a capirlo, lo scriverò domani (dove e come correggerlo).
5. Cosa dobbiamo fare con il galleggiante in FSB? (o con la mancanza di esso in MT) :)?
L'archivio contiene i file necessari, scompattati nella root di MT (l'archivio sarà nel prossimo post)
Buona fortuna a tutti... scrivere :)Archivio degli indicatori attuali (2009-04-15)
Sono d'accordo che il galleggiante non è battuto - è necessario cercare una via d'uscita. Dobbiamo scrivere la corrispondenza. Poi crea una libreria di indicatori. Se posso aiutare, ne sarò felice.