simulatore deltazero ad automi cellulari

Dimentica la binomiale,lo step sul sottostante non è costante
111122 non ha lo stesso valore di 122111 (se lo ha è un caso)
Ora, con albero binario, ogni nodo ha un solo nodo entrante,due percorsi possono avere inizio in comune ma una volta separati in generale non si ricongiungono
Non ci interessa il caso particolare.
In pratica è come dici:ogni nodo ha caratteristiche diverse ma ci può essere una relazione con l'unico nodo che lo predede al livello inferiore



:help::help:
non ti seguo ...
ogni nodo nella binomiale ha due nodi precedenti, ma se la vola la calcoli su uno span temporale un pò più ampio ( 4 nodi?) , è il percorso a definire la vola
.... credo ...
 
:help::help:
non ti seguo ...
ogni nodo nella binomiale ha due nodi precedenti, ma se la vola la calcoli su uno span temporale un pò più ampio ( 4 nodi?) , è il percorso a definire la vola
.... credo ...

Non bisogna usare la binomiale che funziona solo per step costanti
 
Non bisogna usare la binomiale che funziona solo per step costanti


hummm d'accordo
ma per adesso stavo alle ipotesi di Deltazero, come primo modello
col VB non sarebbe un grosso problema fare trinomiale o più ...
o anche 5 rami, e lasciare un generatore di numeri casuale a decidere il ramo
ma così ci allontaniamo dal modello binomiale e andiamo verso la Montecarlo
 
hummm d'accordo
ma per adesso stavo alle ipotesi di Deltazero, come primo modello
col VB non sarebbe un grosso problema fare trinomiale o più ...
o anche 5 rami, e lasciare un generatore di numeri casuale a decidere il ramo
ma così ci allontaniamo dal modello binomiale e andiamo verso la Montecarlo


L'ipotesi di lavoro è una:albero binario (completo),tu fai riferimento all'albero binomiale in cui appunto alcuni nodi si sovrappongono
 
L'ipotesi di lavoro è una:albero binario (completo),tu fai riferimento all'albero binomiale in cui appunto alcuni nodi si sovrappongono

L'ipotesi di lavoro è una:albero binario
sì, sono le colonne da N a R del deltautomi2

a destra, la mappa da W ad AA 'non serve',
nella ipotesi cui stiamo lavorando , ogni percorso 'vive ' una storia indipendente:
il fatto che passino in uno stesso nodo è ininfluente alla analisi della strategia di opz
ma come ci arrivano non è ininfluente
 
:
il fatto che passino in uno stesso nodo è ininfluente alla analisi della strategia di opz
ma come ci arrivano non è ininfluente

certo (se passano per uno stesso nodo sono lo stesso percorso fino a quel nodo)ma appunto non dimenticare che ogni nodo ha un solo padre e che 121 è diverso da 211

ps consiglio ancora di mantenere la codifica binaria 01
Radice (condizioni iniziali) senza etichetta,o con etichetta qualsiasi non compresa nel vettore delle etichette
 
cibovoglia.jpg


se capitano o brain o altri interessati postano qualcosa farebbe piacere
darebbe il senso del team

chiedo venia ... è vero ma in sti giorni opero sul veloce e arrivo alla sera che son parecchio cotto ... prometto di mettermi al passo :ciao:
 
certo (se passano per uno stesso nodo sono lo stesso percorso fino a quel nodo)ma appunto non dimenticare che ogni nodo ha un solo padre e che 121 è diverso da 211

ps consiglio ancora di mantenere la codifica binaria 01
Radice (condizioni iniziali) senza etichetta,o con etichetta qualsiasi non compresa nel vettore delle etichette


ti ho capito meglio
ma temo ancora che diamo lo stesso nome a cose diverse
per me 121 e 211 sono percorsi (121 è up-down-up ad esempio)



il nodo è definito cartesianamente , x=tempo y=valore
i percorsi, con un for-next, si muovono nello spazio bidimensionale tempo-valore
e il 'nome' del percorso contiene il suo codice, per 'decriptarlo' e utilizzare lo stesso 'nome' anche per le altre variabili ( la vola implicita ad esempio)

quindi, in questo schema, ad ogni nodo si può pervenire da due dei nodi precedenti
ma ad ogni 'mossa' del percorso è definita una sola 'mossa' precedente


ok per la radice .. refuso che correggo alla prossima versione
ok per lo 01 ; semplicemente, la lunghezza del 'nome' spiega quante siano le 'mosse' già fatte , invece di usare una stringa di lunghezza sempre uguale


questo, naturalmente, come proposta e imho :help:
per dare forma definitiva, aspetto di capire quali siano le azioni che Deltazero vuol compiere a ciascun nodo, così da vedere se lo schema che sto formando sia compatibile con le specifiche del progetto :)
 
ti ho capito meglio
ma temo ancora che diamo lo stesso nome a cose diverse
per me 121 e 211 sono percorsi (121 è up-down-up ad esempio)



il nodo è definito cartesianamente , x=tempo y=valore
i percorsi, con un for-next, si muovono nello spazio bidimensionale tempo-valore
e il 'nome' del percorso contiene il suo codice, per 'decriptarlo' e utilizzare lo stesso 'nome' anche per le altre variabili ( la vola implicita ad esempio)

quindi, in questo schema, ad ogni nodo si può pervenire da due dei nodi precedenti
ma ad ogni 'mossa' del percorso è definita una sola 'mossa' precedente


ok per la radice .. refuso che correggo alla prossima versione
ok per lo 01 ; semplicemente, la lunghezza del 'nome' spiega quante siano le 'mosse' già fatte , invece di usare una stringa di lunghezza sempre uguale


questo, naturalmente, come proposta e imho :help:
per dare forma definitiva, aspetto di capire quali siano le azioni che Deltazero vuol compiere a ciascun nodo, così da vedere se lo schema che sto formando sia compatibile con le specifiche del progetto :)

ottimo

nella mia testa il nodo aveva 1data e 1livello ,ma anche la targa che è 1 sola (identifica il percorso fino a li)

cmq alla fine arriviamo allo stesso punto con parole diverse ,non è 1 problema


"per dare forma definitiva, aspetto di capire quali siano le azioni che Deltazero vuol compiere a ciascun nodo, così da vedere se lo schema che sto formando sia compatibile con le specifiche del progetto "

in realtà tu hai capito cosa voglio fare valuta tu il meglio

in quello mio semimanuale, mettiamo a 32 percorsi , ho 160 nodi in cui devo:
calcolare il valore del portafoglio iniziale a quel nodo
calcolare tutti gli indicatori che ritengo utili
controllare se si sono verificate condizioni che danno la morte o la modifica del portafoglio e nel caso farle

questa è la prima parte che secondo me
a)come calcolo si concretizza in 1 tabella di 160 nodi
32 righe x 5 colonne
b)graficamente va a concretizzarsi in quei 2 grafici che avevo abbozzato sopra

punto a)
io la vedo come tabella perchè in analisi successive devo avere la possibilità di sommare 2 griglie con stesso ambiente,ma con automa differente

facciamo il caso + semplice

il ns automa è +call 20000 ,nessuna condizione

il grafico finale a 3d avra la classica curva della call ,tutti i percorsi pieni

sempre +call 20000 ,ma a +10% -10% morte

garfico finale classica curva della call ,ma esistono percorsi vuoti

se sottraggo la tabella relativa al primo grafico dalla tabelal relativa al secondo ottengo il garfico relativo alla condizione +10%-10%
 
fermo per ovvii motivi
pensato cmq al prototipo, che per semplicità di costruzione e debugging inizierei a fare solo con un acq del sottostante
 

Users who are viewing this thread

Back
Alto