Rappresentazione di un oggetto nella programmazione. - pagina 17

Nuovo commento
 
transcendreamer #:

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:

  • Scegliamo un insieme di parametri per un nuovo stato dall'insieme iniziale dei parametri del costruttore di funzioni, inventiamo nuovi valori per loro e li scriviamo nel blocco di memoria allocato.
  • Dato un solo stato aggiuntivo di un'etichetta, incontriamo automaticamente la necessità di costruire un modello di eventi, perché se un'etichetta ha almeno UN altro stato, ad un certo punto deve passare ad esso, e quindi dobbiamo descrivere un evento associato all'ambiente o ad un altro oggetto che farà entrare l'etichetta in uno stato alternativo. Cioè, un nuovo stato aggiunto richiede logicamente almeno una descrizione di evento per passare a uno stato alternativo, e (opzionalmente) una seconda descrizione di evento per tornare allo stato iniziale o a qualche altro stato.
  • Da qui la semplice tesi: ogni nuova aggiunta di stato all'Oggetto comporta l'aggiunta di almeno uno, e preferibilmente due nuovi eventi, la cui descrizione deve essere posta nelle condizioni dell'Event Model, che, come sappiamo, è una sorta di "meccanismo di comunicazione" dell'Oggetto e dell'Ambiente e descrive la loro interazione attraverso la sua logica. A priori, solo la presenza di SM può far passare l'Oggetto da uno stato all'altro. Conclusione:+ 1 Stato oggetto = +2 Eventi oggetto o ambiente + 2 condizioni SM.
  • L'aggiunta di Stati Oggetto comporta l'aggiunta di Eventi di Cambio di Stato Oggetto e diventa necessario dare priorità ai nuovi Eventi, e la struttura gerarchica è la più adatta per questo. Contemporaneamente alla comparsa di nuovi Eventi e Stati, l'albero delle condizioni cresce. Il comportamento dell'Oggetto si arricchisce di una varietà di reazioni alle interazioni esterne con le cose "coinvolte" nella sua vita e bisogna dire che più la complessità va avanti, più il contatto esterno è ampio. Si scopre che non possiamo considerare la complicazione dell'etichetta in isolamento dal suo ambiente e abbiamo bisogno dell'ambiente di interazione, altrimenti i nuovi stati diventeranno "peso morto" nella memoria e l'unico evento possibile del loro cambiamento sarà il timer interno.
  • Abbiamo scoperto che non ha senso creare gli stati del nuovo Oggetto senza eventi che li colleghino in modo inseparabile con gli oggetti dell'ambiente, così come non ha senso aggiungere eventi al di fuori del Modello degli Eventi collegandoli con gli stati e i processi dell'Oggetto.Nel processo di complicazione dell'Oggetto, è necessario aggiungere tutto in una volta - Stati, Eventi, condizioni del Modello degli Eventi (organizzandolo in ordine gerarchico contemporaneamente) e creare la relazione Evento->Stato o... Evento->Processo ecc.
  • Aggiungere un Object Process non è fondamentalmente diverso dall'aggiungere uno Stato e l'unica differenza è la quantità di memoria da allocare. Il nuovo processo, così come lo stato, richiede la definizione di eventi di base per se stesso, come: start-events, switch-events, stop-events...


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 Expert Advisor, ha bisogno di più lavoro, sto testando circa 100 dollari al giorno su eurusd e usdchf
 
Ruslan #:
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

 
Ciao ragazzi, potete sistemare questo ;le espressioni non sono permesse in un ambito globale strategy("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0)
 
Voglio rivelare le illusioni mie e altrui (se ho contribuito involontariamente alla loro apparizione) riguardo al cosiddetto "algoritmo della complicazione" e riportare gli appassionati lettori alla dura realtà, dove l'universo stesso nega qualsiasi forma e variazione di"graal" e mostrare che il mio ragionamento è il prodotto di una mente infiammata dall'amore per la filosofia e dalle notti insonni a inventare "perpetuum mobile" o "macchina del tempo", sofferente per la convinzione del proprio genio.
L'algoritmo di complicazione non può essere implementato, o più precisamente, può essere implementata la sua versione "sciocca", dove qualche programma timbra casualmente stati parametrici, eventi, processi e condizioni di qualche oggetto, poi, nella stessa casualità, li compone tra loro e... li cancella e ricomincia. Questa strana azione potrebbe durare per sempre e non è assolutamente chiaro quale sia il suo scopo? Qual è il risultato? Un risultato casuale? E ricordate il problema della funzione costruttore? Come cambiare la sua attuazione? Non è affatto chiaro... Il problema è che il minimo cambiamento nel metodo di implementazione distrugge completamente la "legittimità" di tutte le strutture protoblocco, rendendole inutilizzabili dalla funzione modificata. Tutto sommato, è un compito che richiederà anni, supponendo che sarà risolto dall'Istituto di Ricerca o dall'Accademia delle Scienze, e non il fatto che alla fine qualcosa funzionerà.
L'atmosfera di questo forum è satura di ispirazione graal e getta uno stato d'animo appropriato, da cui quest'ultimo genera parabole sorprendenti, simili a quelle della scienza, che purtroppo non portano mai a niente di pratico, però... ...anche se sono energizzanti per tutti. :)
Non giudicare troppo duramente, ero solo su un "calcio filosofico")))
 
Merda, sta aumentando di nuovo? È appena diventato silenzioso.
 
Реter Konow "graal", e mostrare che il mio ragionamento è un prodotto della mente infiammata dall'amore per la filosofia, che passa notti insonni a inventare "perpetuum mobile" o "macchina del tempo", soffrendo la fede nel proprio genio.
L'algoritmo di complicazione non può essere implementato, o più precisamente, può essere implementata la sua versione "sciocca", dove qualche programma timbra casualmente stati parametrici, eventi, processi e condizioni di qualche oggetto, poi, nella stessa casualità, li compone tra loro e... li cancella e ricomincia. Questa strana azione potrebbe durare per sempre e non è assolutamente chiaro quale sia il suo scopo? Qual è il risultato? Un risultato casuale? E ricordate il problema della funzione costruttore? Come cambiare la sua attuazione? Non è affatto chiaro... Il problema è che il minimo cambiamento nel metodo di implementazione distrugge completamente la "legittimità" di tutte le strutture protoblocco, rendendole inutilizzabili dalla funzione modificata. Tutto sommato, è un compito che richiederà anni, supponendo che sarà risolto dall'Istituto di Ricerca o dall'Accademia delle Scienze, e non il fatto che alla fine qualcosa funzionerà.
L'atmosfera di questo forum è satura di ispirazione graal e getta uno stato d'animo appropriato, da cui quest'ultimo genera parabole sorprendenti, simili a quelle della scienza, che purtroppo non portano mai a niente di pratico, però... ...anche se è energizzante. :)
Non giudicare troppo duramente, ero solo in un "pugno filosofico")))

Se vi trovate improvvisamente in uno stato d'animo cognitivo, leggete la programmazione genetica (spoiler: non potete fare a meno del Bacus-Naurus).

1...1011121314151617
Nuovo commento