Rappresentazione di un oggetto nella programmazione. - pagina 13

 
Aliaksandr Hryshyn #:
Posso fare un esempio?

Un esempio sarà dato un po' più avanti, quando il concetto sarà esposto in modo più completo e più chiaro al lettore.

 

Parte 3.

Per formalizzare il Modello degli Eventi è necessario espandere la natura degli Eventi. Nelle parti precedenti si è assunto che tutti gli oggetti consistono dei cosiddetti "proto-blocchi" - alcune entità specifiche con una base parametrica che vengono utilizzate dalle funzioni di gestione per riprodurre la "vita" degli oggetti-sistema. Si è detto che ogni "protoblocco" ha un "corpo" parametrico che, come una "matrioska", include "corpi" di protoblocchi più piccoli ed è esso stesso incluso in corpi di quelli più grandi. Abbiamo supposto che i protoblocchi possono essere organizzati per livello di complessità in una "gerarchia", dove un Parametro è la più piccola "particella", un insieme di Parametri è il "corpo" parametrico dell'Oggetto, gli insiemi di parametri "scorporati" da questo corpo sono i protoblocchi dei successivi livelli di complessità, tra i quali il primo è la Condizione - la formazione parametrica che dà importanti "punti di rottura" nell'Essere Oggetto, poi, sulla base dell'insieme delle relative Condizioni è il Processo... Fermiamo un attimo lo sguardo sulla struttura parametrica dei protoblocchi menzionati per passare all'Evento e capire come si forma. A questo punto si può affermare:

  • Uno Stato è una costruzione derivata dall'insieme parametrico dell'Oggetto, cioè un "calco" dei parametri selezionati.
  • Uno Stato memorizza istanze importanti dei valori del suo Oggetto.
  • Strutturalmente, i corpi parametrici degli Stati fanno parte dei Processi come "lego-tools".
  • Un processo è una sequenza di stati collegati dalla "vita" dell'oggetto in una catena.
  • Ilprocesso contiene Stati come fotogrammi "cine-film" e viene smontato in essi.

Successivamente, procediamo alla genesi dell'Evento e alla divulgazione della sua struttura parametrica. Dobbiamo scoprire come si forma l'Evento, vedere il "ritratto" parametrico e il suo posto nella gerarchia del protoblocco. Dopo questo, passiamo a "collegare" i proto-blocchi in un sistema funzionale e tracciamo la "nascita" dell'Event Model. Bisogna subito notare che la struttura parametrica di un Evento ha molteplici varianti di combinazioni di attributi permanenti. Facciamo conoscenza con loro:

  • Event Background - un insieme di parametri e i loro valori presi dall'Oggetto o dal suo ambiente (altri oggetti nell'Ambiente) rappresentato come lo Stato iniziale che precede o accompagna un cambiamento significativo considerato come un Evento.
  • Valore target- un insieme di valori da un insieme selezionato di parametri di un Oggetto o del suo ambiente, rappresentato come uno Stato target di quell'Oggetto o del suo ambiente e trattato come un Evento.
  • Differenza obiettivo- la differenza ricercata tra i valori passati e attuali di un insieme selezionato di parametri dell'Oggetto o del suo ambiente,rappresentata come un Eventosignificativo nell' Oggetto o nel suo ambiente.
  • Target Ratio - il rapporto dei valori dell'insieme selezionato di parametri dell'Oggetto o del suo ambiente che è considerato comeun Evento.
  • Firma" dell'obiettivo - il carattere ricercato del cambiamentotra i valori passati e attuali dell'insieme selezionato di parametri dell'Oggetto o del suo ambiente, trattato come unEvento .

Abbiamo elencato i cinque attributi chiave di un Evento inclusi nel suo corpo parametrico in varie combinazioni e che compongono la struttura. L'Evento, come altri proto-blocchi, è costruito da corpi parametrici di Oggetti nella loro vita dinamica e si forma"catturando" i parametri chiave e i loro valori dal momento attuale per un ulteriore calcolo e la registrazione degli obiettivi desiderati - sfondo, valori, differenza, rapporto o firma come modello nel modulo dell'evento (per un ulteriore uso nel sistema). Quando un evento viene generato, i parametri derivati vengono aggiunti al suo corpo per memorizzare i risultati dei calcoli di differenza o di firma. Dovrei aggiungere che è possibile creare un Evento con un gestore-collettore dedicato con le funzionalità necessarie per calcolare gli obiettivi e per il layout parametrico e la registrazione. Naturalmente, Event è più complesso di State e a differenza di quest'ultimo ha una parte "derivata", cioè non è un discendente diretto dei parametri di Object(s) ma è integrato con parametri per i risultati del calcolo delle differenze o la natura dei cambiamenti dei parametri iniziali, ma strutturalmente è lo stesso proto-blocco di State o Process - cioè un insieme di parametri con istanze di valori.

Collegare i protoblocchi in un sistema.

Ora abbiamo la nozione che i proto-blocchi sono formati da gestori-collettori speciali in almeno tre metodi:

  1. Il metodo di "staccare " dal corpo parametrico dell'oggetto quando si costruisceuno stato o un processo.
  2. Un metodo percatturare i parametri e i loro valori dal momento attuale dell'Oggetto o dell'Ambiente - per fissare uno "sfondo", un valore target o un rapporto target, quando si costruisce un Evento.
  3. Un metodo per aggiungere e calcolare parametri derivati speciali peruna differenza di target o una firma di cambiamento di target, anche, quando si costruisce un Evento.

E ora, passiamo alle domande"come costruire un Sistema "vivo" daiproto-blocchi disponibili nel concetto e che ruolo gioca il "Modello degli Eventi" in questo?

I due "Meta-processidi vita" chiave di qualsiasi Sistema (Oggetto) sono:

  • Esecuzione indipendente del programma stabilito.
  • Interazione con l'ambiente.

Questi due meta-processi sono intrecciati in uno solo, quando le influenze esterne interferiscono con il processo di esecuzione indipendente e in risposta, il sistema cambia i suoi parametri per recuperare l'equilibrio perso e continuare con il processo di esecuzione indipendente. Nel complesso, questa dinamica è la vita delsistema nel suo ambiente. Per capire come si realizza la relazione tra "azioneesternae reazione interna", dobbiamo aggiungere un'altra componente al concetto, la Condizionalità.

  • Condizione è un protoblocco che collega Causa ed Effetto con altri protoblocchi del Sistema. A differenza del gestore di collegamento dei parametri discusso nella parte precedente, che cambia i valori dei parametri collegati in base a regole o formule impostate al suo interno, Condition NON ha formulato regole e formule di dipendenza - Condition collega i proto-blocchi all'interno di se stesso in catene causa-effetto senza formule e algoritmi. Per esempio: qualche Evento è posto nel "corpo" della Causa, e qualche Condizione è posta nel "corpo" dell'Effetto. Così, controllando e rilevando qualche Evento, includiamo qualche Stato all'interno dell'Oggetto. Senza formule e calcoli. Semplicemente, facendo una transizione diretta da un protoblocco all'altro.
  • Una condizione, come ogni proto-blocco, ha un gestore. In questo caso, l'operatore"if()" funziona meglio, insieme a"then" e"else". Notate che nel corpo di "Cause" (che è messo in"if()") c'è sempre un confronto trail modello e l 'istanza. Se controlliamo Event, prendiamo il suo modello e lo mettiamo in Condition e poi, il gestore di Condition stesso raccoglie un'istanza dai parametri del modello e confronta i suoi valori con l'originale e sceglie una delle due conseguenze ("then" o "else") a seconda del risultato del confronto.
Questo è tutto per ora. Ora abbiamo un insieme completo di concetti per considerare il Modello degli Eventi e ci arriveremo (se interessati) dopo.


 
Реter Konow #:

Parte 3.

La lib (libreria) sarà intuitiva?

 
Реter Konow #:

Assolutamente, ma siamo molto cattivi a gestirlo e spesso dobbiamo sopportare prestazioni molto basse, contro le quali i computer ci sovrastano facilmente).

Noi (la coscienza) siamo solo una piccola parte della funzionalità del cervello, e nemmeno una necessaria... Ma altri aspetti dell'attività nervosa superiore il cervello si comporta bene e può battere qualsiasi computer... la poesia, i quadri, i racconti, la scienza e così via, non ne parlo nemmeno... è più vicino a una pala che a un cervello in termini di intelligenza...

 
transcendreamer #:

La (biblioteca) sarà intuitiva?

Non so quanta esperienza tu abbia nella programmazione, quindi non posso immaginare quanto tu possa capire quello che sto scrivendo. Per un umanista completo il concetto sarà poco chiaro, ma per qualcuno con capacità di codifica molto è abbastanza ovvio. Cercate di formulare domande e io cercherò di rispondere).

Aggiunto: avete molti codici nel vostro codebase, il che significa che avete esperienza. Allora, gran parte del concetto dovrebbe esservi chiaro.

 
Nikolay Ivanov #:

Noi (la coscienza) siamo solo una piccola parte della funzionalità del cervello, e non è nemmeno necessario... Ma altri aspetti dell'attività nervosa superiore il cervello si comporta bene e può battere qualsiasi computer... Non parlo nemmeno di poesie, quadri, racconti, scienza e così via, il computer non c'entra niente... in termini di intelligenza è più vicino a una pala che al cervello...

Sono d'accordo.

 
Реter Konow #:

Non so quanta esperienza tu abbia nella programmazione, quindi non posso immaginare quanto tu capisca di cosa sto scrivendo. Per un umanitario completo, il concetto non sarà molto chiaro, ma per qualcuno con capacità di codifica molto è abbastanza ovvio. Cercate di formulare domande e io cercherò di rispondere).

Aggiunto: avete molti codici nel vostro codebase, il che significa che avete esperienza. Allora, molto del concetto dovrebbe esservi chiaro.

Beh, c'è una libreria standard in mql5, ci sono altre librerie che portano una sorta di sollievo per il lavoro con entità complesse (a volte, però, il contrario è il caso di complicazione inutile) - quindi la domanda è: c'è una libreria, che sarebbe conveniente da usare?

 
transcendreamer #:

Beh, c'è una libreria standard in mql5, e ci sono altre librerie che rendono più facile lavorare con entità complesse (a volte, però, è il contrario) - quindi la domanda è: c'è una libreria che sarebbe conveniente usare?

È difficile da dire. Penso che la realizzazione di un tale approccio non standard richiederebbe di fare tutto con una programmazione di basso livello, senza usare l'OOP standard. Ma forse mi sbaglio.

 
Реter Konow #:

È difficile da dire. Penso che l'implementazione di un tale approccio non standard richiederebbe di fare tutto nella programmazione di basso livello, senza usare l'OOP standard. Ma forse mi sbaglio.

Tutto è fatto

 
Реter Konow #:

È difficile da dire. Penso che l'implementazione di un tale approccio non standard richiederebbe di fare tutto nella programmazione di basso livello, senza usare l'OOP standard. Ma forse mi sbaglio.

L'importante è che per l'utente sia una semplificazione, non una complicazione.