FILES: Book.py, TrendAgents.py, VolumeAgents.py,
BestOffertAgents.py, Model.py
Le evoluzioni del programma presentate in questo capitolo interessano, rispetto alla versione precedente, i seguenti punti:
• modifica di una delle funzioni interne al Book. In questa versione, ogni qual volta un’offerta di acquisto o di vendita perverrà al Book, esso controllerà che lo stesso agente non abbia fatto offerte di “segno29” opposto. Nel caso in cui, l’agente avesse fatto offerte di “segno” opposto in “step” precedenti, il Book le eliminerà.
• creazione di diverse classi, ciascuna delle quali rappresenta un agente diverso. Gli agenti saranno dotati di intelligenza e presenteranno le loro offerte di mercato seguendo una strategia. Alcuni, ad esempio, potranno esprimere la propria offerta confrontando l’ultimo prezzo negoziato con la media mobile di un numero variabile di prezzi negoziati, partendo dal tempo (t-2); altri
29 Con questa espressione mi riferisco alle offerte di acquisto, nel caso in cui al Book pervenga un’offerta di vendita. Viceversa, nel caso in cui al book pervenga un’offerta di acquisto.
esprimeranno la propria decisione in base ai volumi di acquisto e di vendita. Altri ancora avanzeranno offerte “al meglio”, le quali permetteranno loro di concludere una transazione con certezza.
4.1 File: Book.py
In Figura 1 è possibile osservare le modifiche al programma del Book, presentate nell’introduzione del capitolo. La prima condizione “if” verifica che nella lista opposta non ci siano offerte avanzate dallo stesso soggetto proponente l’offerta in questione. Nel caso in cui si trovino offerte con la medesima identità, esse non verranno copiate nella lista, detta “sellList”. Attraverso questa modifica, si eviteranno problematiche future legate al numero eccessivo di offerte elencate in lista. Un altro problema che sarà evitato è quello legato alla “non coerenza strategica”: se un soggetto esprime una volontà di acquisto, nello stesso istante egli non può essere incluso all’interno di una lista per proposte di vendita.
Altro comando visibile in Figura 1 è “self.getVolBuy”. Esso richiama un modulo programmato all’interno della classe “Book”, che tiene il conto del numero di offerte di acquisto pervenute. Specularmente, è presente lo stesso comando per le offerte di vendita, le quali saranno utilizzate dall’agente, che baserà la propria strategia sui volumi di offerte di acquisto e di vendita.
In Figura 2 è possibile visualizzare i moduli di programmazione, che forniranno valori utili alle nuove classi di agenti. “getMaxPriceSellList” fornirà alla classe “UniformVolAgent” il miglior prezzo di vendita presente in lista. Questo permetterà all’agente, facente capo a questa classe, di esprimere un’offerta di acquisto vincente, ogni qual volta fosse chiamato ad operare. Stesso principio ma di segno opposto è quello espresso da “getMaxPriceBuyList”.
“getVolBuy” è il modulo che aggiorna la variabile programmata per il conteggio delle offerte di acquisto. Esso, unito a “getVolBuy”, sarà usato dalla classe che attuerà la propria strategia sulla base dei volumi di acquisto e di vendita.
4.2 File: TrendAgents.py
In Figura 3 è possibile osservare la programmazione della classe “TrendAgent”.
Ogni classe di agenti ha internamente una variabile definita da un’apposita dicitura, che riprende il nome e la natura della classe di appartenenza dell’agente. Questa dicitura è fondamentale per la programmazione, poiché consente di chiamare gli agenti, raccolti all’interno della lista “agentActionList”, ad operare in base alla loro classe di appartenenza. Questa condizione è osservabile all’interno del file “Model.py”. Essi non sono attivi all’apertura dei mercati, ma entrano in gioco qualora un sufficiente numero di contratti sia stato concluso.
Gli agenti che fanno parte di questa classe decidono di acquistare o di vendere in base ad un confronto tra l’ultimo prezzo negoziato e una media mobile di prezzi, variabile
da agente ad agente. Nel caso in cui il risultato della media mobile sia inferiore all’ultimo prezzo negoziato, l’agente farà un’offerta di acquisto, poiché la fase di mercato in cui egli opera è in rialzo. Nel caso in cui, invece, il risultato della media mobile sia superiore all’ultimo prezzo negoziato, l’agente proporrà un’offerta di vendita.
Le offerte di vendita e di acquisto proposte hanno come base di partenza l’ultimo prezzo negoziato moltiplicato o diviso per un coefficiente, che è una variabile uniformemente distribuita tra 1 e 1,2. In caso di acquisto, si moltiplica l’ultimo prezzo negoziato per il coefficiente “self.coefficient”; viceversa, in caso di vendita, l’ultimo prezzo negoziato si divide per il coefficiente “self.coefficient”.
La decisione di offerta è, comunque, legata ad una variabile “random” al fine di aumentare la variabilità del programma.
Altri moduli programmati, ma non visibili in Figura 3, riguardano le istruzioni inviate dal Book alla classe “TrendAgent” per avvisare ogni agente dell’avvenuta transazione.
4.3 File: VolumeAgents.py
“VolumeAgent” è una particolare categoria di agenti, che non considerano
l’andamento dei prezzi di mercato, bensì i volumi di acquisto o di vendita ad ogni determinato istante. Essi agiscono spinti dall’andamento dei mercati verso correnti rialziste o ribassiste.
La classe “VolumeAgent” attraverso la variabile “volSell” e “volBuy”, richiamate all’interno del Book, è a conoscenza in ogni istante della differenza tra i volumi di acquisto e quelli di vendita.
Nel caso in cui la variabile che determina il numero delle offerte di acquisto sia superiore alla variabile che determina il numero delle offerte di vendita, l’agente in questione è maggiormente propenso a seguire il mercato e a proporre un’offerta di acquisto. Viceversa, nel caso in cui il numero delle offerte di vendita sia superiore al numero di offerte di acquisto, l’agente è maggiormente propenso ad avanzare un’offerta di acquisto.
4.4 BestOfferAgents.py
Il programma visibile in Figura 5 determina il comportamento dell’agente, che propone offerte vincenti ad ogni sua azione. Il differenziale tra i volumi di vendita e i volumi di acquisto fornisce all’agente l’input per operare. Avendo inserito una classe che non valuta i prezzi di mercato, bensì i volumi, è molto probabile che si creino correnti di agenti che propongono solamente offerte di acquisto e correnti di agenti che propongono solamente offerte di vendita. La categoria degli agenti “BestOfferAgents” smorza questa possibilità.
La classe “BestOfferAgent” ingloba la classe “VolumeAgent”, acquisendo, così, i metodi propri di quest’ultima, nonchè i nuovi moduli programmati.
In Figura 6 è possibile notare il particolare della classe “Model” che permette di individuare, all’interno della lista “agentActionList”, le diverse tipologie di agenti ed i rispettivi comandi richiamati.