![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
72 casi, 24 nuovi casi speciali, sistema di scrittura non lineare, grammatica a matrice, morfosintassi, boustrophedon, e fonetica speciale - proprio quello di cui le sette commerciali più cool hanno bisogno (così i Chekisti e i Massoni non possono rubare il Graal).
Sì, dovremmo sicuramente tradurre la frase "incrociare due medie mobili" in Ifkuil)
A causa del fatto che l'argomento di questo tema è in gran parte filosofico e non si adatta non solo ai confini dell'algotrading, ma anche (in alcuni punti) della programmazione in generale, ho deciso di completare la serie di parti del concetto con una teoria finale di "algoritmo di complicazione", delineando la sua comprensione e rispondendo alla domanda - può esistere un tale algoritmo in principio?
Come previsto, considereremoil "meccanismo di complicazione" sull'esempio di un semplice marcatore rettangolare sullo schermo di pixel, disegnato chiamando una funzione grafica composta da due cicli annidati (altezza e larghezza) e utilizzando 5 parametri di base - x, y, larghezza, altezza, colore.
Chiameremo la funzione di disegno il "costruttore" e il suo parametro impostato l'Oggetto. Va notato che, per quanto la maggior parte della gente pensi,un Oggetto è un "sottoinsieme" di pixel separati per colore e combinati geometricamente in un insieme comune di pixel dello schermo, ma per il programmatore, un Oggetto non è solo una forma esterna, percepita dall'occhio, ma anche creando il meccanismo stesso. Un'etichetta, come sappiamo, è "costruita" in due cicli dalla funzione di disegno, il che significa che la funzione con i suoi parametri è anche un'"etichetta". Non un rettangolo colorato, ma l'algoritmo con i parametri che lo disegna. Questo punto è difficile da realizzare, poiché la persona è abituata alla percezione visiva di un guscio di oggetto e considera il codice che sta dietro di esso come qualcosa di inverosimile e secondario, tuttavia - è l'Oggetto stesso, dopo tutto in caso di qualsiasi cambiamento di implementazione della funzione iniziale o dei valori dei suoi parametri il cambiamento esterno di un guscio segue inevitabilmente.
Trovo più facile separare il set di parametri di una funzione dalla sua implementazione interna e trattarlo come l'oggetto principale, anche se naturalmente questo non è vero, perché l'implementazione interna della funzione costruttore e il suo set di parametri sono inestricabilmente legati. Tuttavia, l'implementazione interna cambia molto meno frequentemente e questi cambiamenti sono più fondamentali che, ad esempio, i cambiamenti nei valori dell'insieme parametrico, che sono facili da lavorare e da sperimentare. Se il metodo di implementazione della funzione costruttrice cambia, allora nasce un nuovo insieme parametrico, e questo comporta modifiche a tutti i "proto-blocchi" costruiti sulla base del vecchio insieme parametrico della funzione costruttrice. Cioè se abbiamo inizialmente costruito uno stato alternativo dell'etichetta con 5 parametri:x, y, larghezza, altezza, colore con valori diversi e poi lo "abilitiamo" a qualche evento, allora un cambiamento inaspettato del metodo di implementazione della funzione-costruttore, che riduce il numero di parametri, diciamo, a 3, cambierà la struttura dell'insieme parametrico primario (da cui probabilmente sono già stati creati altri stati, eventi o processi) e la precedente costruzione dello stato alternativo dell'etichetta "collasserà", diventando inutile per la nuova versione della funzione-costruttore. Qui ci troviamo di fronte al primo grande ostacolo dell'implementazione dell'algoritmo di complicazione: il metodo di implementazione della funzione-costruttore pone dei limiti al potenziale di complicazione dell'oggetto. Superare questi limiti senza l'intervento umano di qualche algoritmo è una complicazione automatica.
Consideriamo una complicazione sperimentale "semplice" di un'Etichetta senza cambiare il metodo originale della sua implementazione della funzione-costruttore e senza entrare nel senso della complicazione - cambieremo solo i valori del suo set di parametri e "deriveremo" nuovi stati sulla sua base e vedremo a cosa si arriva:
Conclusione:
Certo, bisognerebbe scrivere più di un libro e non basterebbe un solo post, ma è già ovvio che se definiamo lo scopo della complicazione a qualche programma, in modo che crei modelli di Oggetto con vari Stati, Eventi, reazioni all'ambiente, anche senza cambiare l'implementazione di una funzione-designer e basandosi su un set parametrico fisso, probabilmente, dopo un'ennesima quantità di prove ed errori, potrebbe creare un'etichetta che esegue qualche compito semplice, ma tale programma dovrebbe "essere in grado" di costruire "proto-blocchi" - stati, eventi, Sono ottimista, anche se posso immaginare la complessità di un tale compito.
Ciao a tutti ho un consulente esperto ho bisogno di più dettagli se qualcuno è bravo a farlo ora provo circa 100$ al giorno su eurusd e usdchf
sarà...
gli oggetti in esso sono rappresentati in modo errato :-)
PS/ garantito per fallire, indipendentemente dagli oggetti
Se vi trovate improvvisamente in uno stato d'animo cognitivo, leggete la programmazione genetica (spoiler: non potete fare a meno del Bacus-Naurus).