• Aucun résultat trouvé

A Multi-Agent Decentralized Architecture On Market Operations

N/A
N/A
Protected

Academic year: 2022

Partager "A Multi-Agent Decentralized Architecture On Market Operations"

Copied!
11
0
0

Texte intégral

(1)

A Multi-Agent Decentralized Architecture On Market Operations

Maxime Jumelle, Benjamin Dallard

https://aipcloud.io {maxime,benjamin}@aipcloud.io

November 7, 2018

Abstract

The portfolio selection problem has received considerable attention in both the financial and statistical literature. When coupled with Artificial Intelligence and Cloud services data exploitation has shown crucial result through a myriad of projects. We believe that the next agent technology wave will be introduced by the trading expert analyst agent systems, based on applied AI, accessing some specialized knowledge data base. Thus, in this paper we introduce a Procedural Reasoning System approach for the problem of choosing a sequence portfolios over time to maximize a measure of performance that is appropriate for risk-return preferences of an investors. It address two important concept, the portfolio optimization and the distributed Artificial Intelligence.

1 Introduction

In Distributed Problem Solving (DPS), we can process a complex task using a network of semi- autonomous processing nodes working together to solve a problem. Because Multi Agent System (MAS) and DPS are complementary research agendas[1], we present a Procedural Reasoning Sys- tem (PRS)[2][3] approach for market trading operations that we call Multi-Agent Decentralized Architecture On Market Operations.

In a MAS, agents should be able to interact with each other and with their Cloud Environment in an adaptative manger. We will have brief discussion about architecture, communication types and coordination models between agents but we will not detail each agent optimization techniques in this paper. However we consider every agents goals are to optimize functions such as portfolio value or risk and cost functions across timet, generally call(Wtn)n∈N.

1.1 Architecture

The introduction of artificial intelligence methods in investment portfolio management and the rise of machine learning have drawn a lot of attention to the field. In recent years there has been a considerable growth of interest in cloud computing and MAS. Thus we present in this paper an PRS approach for market trading operations. Agents can be described as distinct entities with standard boundaries and interfaces designed for problem solving such as optimize functions.

Each agent typically has a local view of the environment, they learn how to respond promptly to unexpected events while simultaneously carrying out their task. Indeed agent technology is especially suitable to address issues concerned with portfolio management domain. Sycara, Decker and Zeng[4] analyzed the task of the portfolio management domain and they pointed that this is the task of providing an integrated financial picture for the management of an investment portfolio over time, using information resources over the internet.

Even though there are several agent based approaches reported in literature like the ORACLIA[5]

and MASST[6] models which the tasks of gathering data, predicting trend and choosing assets are divided between specialized cooperative agents. In our architecture agents are able to monitor and extract the stock market information in the "Pairs set" via Exchange APIs and using Intentions

(2)

Figure 1: Agent Architecture

and Knowledge Areas (KAs) provided in the form of mathematical models in order to achieve the established goal. Thus,every agents core is defined into five components : Goal, KAs, Knowledge Basics (KBs), Intentions and Interpreter. Below a synthetic scheme of the agent core architecture.

For the Agent part; goal is to optimize such functions as portfolio value or risks and costs func- tions. Knowledge Areas define sequences of low-level actions toward achieving a goal in specific situations. Knowledge Basics is the beliefs about the world, represented using dynamics informa- tion. Intentions include those KAs that have been selected by models for current and eventual execution. Finally the Interpreter component or inference mechanism that manages the system and makes decisions.

For the Cloud Environment part; pairs set of resources defined by the maintainer. Data Ware- house that include historical data and specific data from the maintainer. The next step is to incorporate these agents inside "host" machines to handle queries, provide information or execute some tasks. Thus we need to talk about communications tools between agents into their Cloud Environment.

1.2 Communication

The interest of MAS is that they can manifest self-organisation and complex behaviors even when the individual strategies of all their agents are simple. When agents can share knowledge using any agreed language, within the constraints of the system’s communication protocol, the approach may lead to a common improvement of the system. In the second part we present an approach with the languages Knowledge Query Manipulation Language (KQML).

In order to ensure an organize share of knowledge between agents we defined a hierarchy calls

"Maslow’s hierarchy" which define a state ω for each agent. To achieve its goal, an agent can search in different ways. In one variation called independent search an agent selects an initial port- folio and follows the selection rule without communication with other agents In another variation called cooperative search agents can communicate about the recent performance of their portfolio strategies. Like[7] we based our architecture on both approaches that we differentiated withω.

In Section 2, we introduce a decentralized architecture and how agents will sociabilize and com- municate together. In Section 3, a brief example of application on crypto-market operations is detailled to demonstrate how this architecture could be implemented in a real world situation.

Finally, on Section 4, we discuss of future works, improvements that may improve efficiency and point out actual weaknesses in our architecture.

2 Cloud Ecosystem

One of the biggest goals of self-organized system is building a fully sustainable ecosystem through a decentralized architecture. In this ecosystem lies a multitude of agents, which are piloted by

(3)

intelligent and autonomous algorithms. All agents will have the opportunity to communicate with each other in an unsupervised way. Moreover, considering agents as independent of any obstruction of operation, agents will be autonomous as well in their management of resources (financial for instance) as in their mode of operation. To ensure this sustainability, it is required to establish a certain autonomy avoiding giving full power to a particular agent, including changes in operations that could lead to a sudden imbalance to all agents communicating with him.

In the interaction logic of agents, we consider a discrete timeline(ti)i≥0, that is to say that ti+1=ti+ ∆t ∀i∈N

witht0 = 0and∆t >0 referred asupdate frequency. Each update of the resources, thus the one of the portfolio, are carried out at each timeti. We define the portfolio at every moment.

Definition 2.1(Portfolio). A portfolio(Wtπn)n∈Nwith allocation strategyπis a real valued discrete stochastic process.

We will come back to the allocation strategyπlater. Indeed, this strategy, which is to be defined at the early stages of development of the module, allow to specify the financial resources allocated for the future actors. This is particularly important when it comes to optimization problems, such as market operations (portfolio management, asset management), or more generally resources optimization (energy, delivering, etc).

2.1 The Maslow’s Hierarchy

Always with the aim of promoting an efficient autonomous ecosystem while being reliable and secure, it is essential to define the needs for each agent. Indeed, impacts on the ecosystem are not identical if the needs of an agent are basic or, on the contrary, high. This is how we define, for each agent, astate, which allows both to characterize the current needs of an agent, but also to obtain information about the possible future survival of this agent.

Definition 2.2(States). An agent’s state ωti at timeti takes values into the following set {Standalone,Enhanced,Actualized,Failure}

The first three states correspond to the case where the module has the requirements respectively basic, intermediate and high. Finally, theFailurestate is used to indicate the survival of a module.

Indeed, it is necessary to ensure the viability of a module to be able to change its needs or, otherwise, keeping it in the current state to avoid downgrading or removing it from the ecosystem. We thus rigorously define theFailurestate according to the value of the portfolio.

Definition 2.3(Failurestate). An agent with portfolioWtπn is in stateFailureat periodtn if Wtπn≤0

Failure state is triggered even if we have exactly a 0 valued portfolio, to ensure that no

"sleeping" agents coexists in ecosystem. As we will see later, this condition can not always be verified deterministically : in particular, we prefer reasoning from a probabilistic point of view to characterize theFailurestate. TALK ABOUT WHY WE DEFINE A FAILURE STATE

At the beginning, an agent is in Standalone state. From this point, we have two actors that only interact with it.

• The Maintainer, with fully-determinist contributions S0(t), which has paternality over ecosystem. Main role of Maintainer is to manager entire ecosystem (creating or removing agents) but also to provide sustainable environment with an efficient strategy. This strategy, which is not discussed in this paper, has to ensure viable existency according toMaintainer needs and objectives. InStandalonestate, we assume thatMaintainercan only contribute financially1or obtaining withdrawalsν(t)from agent.

1In market operations, this contribution is financial, but it can also be considered as a contribution of resource (energy or token access for example).

(4)

Figure 2: Actors involved during portfolio update (1). Maintainercan brings contributionS0 as he can also retrieve withdrawals ν. Since agent also lives on a possibly infrastructure that does not belongs toMaintainer, agent also has to support life costCLtoHost.

Figure 3: Simulation of a portfolio without any rentability. We suppose constant cost life CL(t) = 2, one withdrawal ν(t) = 21{t=10}and contributions equals to1plus5every four updates, with S00 = 8. Contributions are always computed before life cost to prevent any Failure state if Maintainerbrings contribution just before payment of life cost.

• TheHost, referred as an infrastructure where agent’s algorithm is executed. Since it is based on a decentralized cloud architecture, and because agents are computed on distant machines, agents execution has a financial cost, namely alife cost onHost. This life cost is defined thanks to the following stochastic process

CL(t) =µL(t) +σL(t)B

Where B is a random standard gaussian variable. Also, agent’s algorithm can be located onMaintainer’s own infrastructure, therefore life cost can be negligated. However, we will assume thatHostandMaintainerare not same entity (except under specific assumptions).

Life cost is composed of a deterministic part, meanµL, and a stochastic part, σLB, where σL is volatility of cost. These informations are supposed obtained fromHost, according to its own knowledge of his infrastructure (such as Cloud providers), and is not directly com- puted byMaintainer, although this one can certainly estimate those parameters. During communication routine, which is addressed later, compute life cost given prior information obtained fromHost. Eventual transactions fees aresupposed included in life cost.

Let us focus on actors’ interaction with agent. Since agent is living on a server, owned byHost, it has to pay his life costs, deduced from the portfolio. TheMaintainer has possibility to bring financial contribution at any time, but also obtaining withdrawals from it. This process, executed at each time step, is rewritable as a recurrent equation on portfolio for each periodti :

Wtπi=Wtπi−1+S0(ti)−CL(ti)−ν(ti) (1) Update equation is a central key in agent’s life, as communication within ecosystem is required through requirements based on portfolio conditions. Still, we have not yet detailled allocation strategy : asset management operations become available only when agent is at least in state Enhanced. Figure2 shows how this process is visually operating. First statement we see is that agent is in Failure state as long as S0(ti) = 0for all i≤ M for a certainM ∈N. Because an

(5)

agent must not be inFailurestate, it is needed to define conditionson how an agent can reach higher states, and then being able to exists and communicate with others agents in ecosystem.

Definition 2.4(Nearly-Infinite Execution Time Condition). LetTFailureN be defined as follows TFailureN = inf{n >0 :E(Wtπn)≤0}

ThenNIETcondition is fulfilled if the following assumption is satisfied.

TFailureN =∞ (2)

As discussed before, the NIET condition is required to switch state from Standalone to Enhanced. This means we must be sure that, for any periodtn, state cannot be inFailure.

Proposition 2.5. In Standalonestate, if there are no life cost or withdrawals (i.e. CL=ν= 0) and∃k∈N, St0

k>0 thenωtj =Enhancedfor allj≥k.

Proof. In this particular case, we know that Wtπn+1 = Wtπn+S0(tn) = Pn

j=0S0(tj) so if ∃k ∈ N, S0(tk)>0then, for allj≥k,E(Wtπj)>0implyingTFailureN =∞.

In case where bothMaintainerandHostare the same entiry, a single requirement to satisfy NIETcondition is to bring a strictly positive contribution. In this case, first needs are automati- cally fulfilled and an agent can begin to grow.

2.2 Standalone’s principle

Proposition 2.6. Let us suppose thatσL(t) = 0(life cost is deterministic). ThenNIETcondition is satisfied if∀i∈N, S0(ti)> µL(ti) +ν(ti).

Proof. We are in the case where costs life cost is known for everyt≥0. Then we can write portfolio value as

Wtπi =Wtπi−1−(µL(ti) +ν(ti)) +St0i Then, for alln∈N

E(Wtπn) =

n

X

i=0

{S0(ti)−(µL(ti) +ν(ti))}>0 (3) Using the assumption from the proposition. We immediatly see thatTFailureN =∞, fulfilling the NIETcondition.

The previous proposition is, in fact, a lot restrictive. Indeed, it requiresMaintainerto bring contributions whenever there are costs. But this assumption has no memory : for instance, we can have residuals contributionsS˜0(ti) =S0(ti)−(µL(ti) +ν(ti))>0 which, stacked over a certain period of time, can requires a lot of tokens. It is easy to show that we can introduce a weeker condition onS0(ti), still satisfyingNIETcondition but less restrictive toMaintainer. Still under assumptions of (2.6),NIETcondition is fulfilled if sum of residuals contributions is always strictly positive i.e. for alln∈N

n

X

i=0

0(ti)>0

A quick look at the equation allows us to show that if (2.6) is satisfied then this proposition is automatically satisfied as well. However these propositions are not equivalent.

In the previous propositions we proved that strictly positivity of the sum of residuals contributions is a sufficient condition to fulfill theNIET condition. But we can also prove that assumptions of

??are necessary conditions, whether costs are deterministic or not.

Proposition 2.7. Strict positivity of sum of residuals contributions is anecessaryandsufficient condition to fulfillNIETcondition.

(6)

Figure 4: Example of agent satisfyingNIETcondition but still entering inFailurestate. Volatil- ity of life cost is linearly growing as time is ticking. Expectation of portoflio (red curve) is always strictly postive. However, as we can see, portfolio value Wtπn can somehow decrease down below0(red dots).

Proof. We know that

TFailureN =∞ ⇔ ∀n∈N,E(Wtπ

n)>0 We know thatE(B) = 0thenE(CL(t)) =µL(t)for allt≥0. Therefore

E(Wtπ

n) =

n

X

i=0

(S0(ti)−E[CL(ti)]) =

n

X

i=0

0(ti)>0

The NIET condition has a big issue. It is possible that portfolio expectation is always strictly greater than0, but nothing prevent portfolio value decreasing below0, as shown in figure4. This is due to centered property of gaussian model, which, whatever volatilityσis allocated to life cost, expectation is always equals to deterministic part. In order to take into account this effect, we have to introduce more restrictive conditions.

Definition 2.8(Surely-Infinite Execution Time Condition). LetTFailureS be a stopping time defined as

TFailureS = inf{n >0 :Wtπn≤0}

Then theSIET condition is fulfilled if the following assumption is satisfied.

P(TFailureS =∞) = 1 (4)

This condition is relatively strong, which requires very restrictive conditions on portfolio. For instance, using non null deterministic volatility will automatically invalidate previous condition.

Indeed, because of gaussian modelling, there always exists a probability, as small as possible, that portfolio value decrease below0. We then introduce a weaker condition that could be more suitable in exploring future reliability of our portfolio.

Definition 2.9(Expected-Infinite Execution Time Condition). TheEIETcondition is fulfilled if the following assumption is satisfied.

E(TFailureS ) =∞ (5)

Since the previous condition is weaker, we can directly prove the following implication.

(7)

Proposition 2.10. We have the following diagrams

SIET⇒EIET SIET⇒NIET

Proof. SinceP(TFailureS =∞) = 1thenP(TFailureS ≥n) = 1for alln∈N, so E(TFailureS ) =X

n∈N

P(TFailureS ≥n) =∞

For the second diagram, we know that

TFailureS =∞ = \

n∈N

Wtπ

n>0

Stating that∀n∈N,P(Wtπn≤0) = 0help us to conclude.

NOW DECIDE WHICH CONDITIONS TO USE IN ENHANCED STATE

2.3 Market environment

If, and only if, agent’s state isEnhanced, it is allowed to manage financial assets belonging outside ecosystem. This state can be considered as a Proof-of-Work (POW), similarly as a promising agent that has to perform well under certain conditions to be considered as effective, and then reaching the higher state Actualized. To do so, it is important to define exactly how portfolio is evaluated at each time step. We suppose that an agent can managep financial assets, whose

"nominal" value at time t is denoted as Xtk, where k is the k-th financial asset. For instance, we could suppose having financial crypto-assets in BTC, ETH and XRP, and we would like to compute portfolio current value (at timet) inUSD, so everyXtk for1≤k≤3 refers to estimated quantity ofBTC,ETH andXRP evaluated in USD.

From now, our portfolio value is based on Xtk calculations, and since agent has to manage his own assets selection, the assets value is determined according to allocation strategy πt = (π1t, . . . , πpt) at time t, where πkt ≥ 0. We add an extra variable Xt0 corresponding to portfolio value in ground currency, but as we are performing on market operations, we are not interested in optimizing this variable. In our previous example,Xt0 would refers to amount ofUSD available in our portfolio. In order to make calculations easier, we consider a intrinsic functiongwhich contains all financial movements linked to cost life and contributions, so asg(t) =S0(t)−CL(t)−ν(t)for every time t. To reduce notations, we write G(t) all financial movements linked to cost life and contributions performed to datet, i.e. G(t) =P

t0≤tg(t0). Finally, in stateEnhanced, our portfolio value is computed as follows

Wtπ=G(t) +

p

X

k=1

πktXtk+Xt0 (6)

maxπ Wtπ= max

π p

X

k=1

πktXtk

2.3.1 Evaluation’s measure on performance

Before accesing sociability features and ability to take decision according to others agents living in the ecosystem, it was previously stated that a Proof-of-Work has to be clearly defined and executed.

To do so, we propose several measures to evaluate market performance and self-sustainability of an Enhancedagent before it can accessActualizedstate. Asreturnsare easy-to-compute measures that has advantage of an interpretability property, a natural choice to evaluate performance of an agent is to evaluate his portfolio’s return between two periodstandt0 :

R(t, t0) = Xt00+Pp

k=1πkt(Xtk0−Xtk)−Xt0 Xt00 +Pp

k=1πktXtk−Xt0 (7)

The way to use this measure rely on Maintainer risk aversion and market strategy. As an example, let us suppose that agent are not supposed to performdangerous operations, and only

(8)

agents that can generate benefits on a short-term period are allowed to communicate, we only detect if portfolio’s return since stateEnhancedis over a certain thresholdη :

R(0, T) = XT0+Pp

k=1πTkXTk +X00

XT0−X00 ≥η (8)

Is some cases, if we wish to obtain a return of at least1%regarding initial investment, we could setη= 0.01and check returns on3-days periodic times. The opposite, i.e. defining a thresholdξ at which agent loose more money that we can supportR(0, T)≤ξis also suitable to safely trigger aFailurestate and not wasting much money onEnhancedagents, acting as a stop loss.

2.4 Sociability

To ensure a certain level of abstraction but essential clarity in agent communication, this whole sociability relies on KQML [8]. First, abstraction is ensured because KQML is independent of etc...

In this architecture, VKB (Virtual Knowledge Base) is assimilated as a list of external marketplaces (exchanges in case of crypto-currencies, FOREX for currency trading, ...) where we suppose access is possible without any cost2.

2.4.1 Facilitators

As defined in [8], our ecosystem containsfacilitatorsthat enables to ensure information retrieval between multiple agents that are not aware of their neighbors existency. A specific example will be detailed later on the next section. Most advantages of facilitators resides in their behaviour as a communication gate, which prevent spurious communication inside ecosystem. These can be considered as centralized communication query databases, or "data hub", although their physical state is not necessarily centralized, but this aspect is not discussed in this paper. Readers that requires more information are advised to read ??? for more information on the subject.

Figure 5 shows a recruitement process taking place in the ecosystem. Suppose that an agent trading on aBTC pair needs information, named R_XRP of an agent that trades on XRP pair.

A usual communication scheme would imply only both of them : BTC agent asks this information toXRP agent, and gets response from it. However, in our decentralized case and as we developed and self-sustainability system, this potential XRP agent may not be existing at the momentBTC asks an information. To overcome this situation, we introduce a facilitator that will trigger an action as soon as an XRP agent detaining requested information is available. Here, the BTC agent will ask the facilitator to receive request thanks to recruit performative. Indepdendently, an XRP agent can notify facilitator that it effectively has requested information with advertise performative. From now, instead ofbroker performative, we allow direct communication between both agents, withask andtell performatives, as it would have be done in a direct point to point protocol.

Listing 1: KQML Dialogue when Agent reachesEnhancedstate.

( a d v e r t i s e : s e n d e r Agent : l a n g u a g e C : o n t o l o g y s t a t e

: c o n t e n t ( i n t SIET = 1 ; ) )

Listing 2: KQML Dialogue when Agent reachesActualizedstate.

( a d v e r t i s e : s e n d e r Agent : l a n g u a g e C : o n t o l o g y s t a t e

: c o n t e n t ( i n t BVP = 1 ; ) )

2Realistically, there are quite always costs directly associated to usage of VKB. In our case, we would easily suppose that these costs are automatically plugged in returns and/or in life costs of agents.

(9)

Figure 5: Two actions located can be performed independently. IfBTC agent recruit at timetandXRP agent advertise at timet0, then given performative is processed at timemax(t, t0).

Listing 3: KQML Dialogue of simple com- munication between two agents.

AgentXasks return ofAgentY since itsActualizedstate.

( ask−one

: s e n d e r AgentX : r e c e i v e r AgentY : l a n g u a g e KIF : o n t o l o g y comm

: c o n t e n t ( v a l ( r e t u r n ) ) )

Listing 4: KQML Dialogue of simple com- munication between two agents.

AgentXasks return ofAgentY since itsActualizedstate.

( ask−one

: s e n d e r AgentY : r e c e i v e r AgentX : l a n g u a g e KIF : o n t o l o g y comm

: c o n t e n t (=( r e t u r n ) ( s c a l a r R(0, t)) ) )

3 Application

In this section, we propose an application of this architecture in case of decentralized trading agents on crypto-assets trading. Because seeking performance on portfolio relies on trading strategies developed byMaintainer, each of these agents belongs to astrategy group, where all agents inside the group seek performances using similar trading strategies. In this application, we introduce three strategies in the ecosystem :

• A low-risk strategy, represented as the first group, which is composed of two agents trading on BTC/USD pair. These agents has to provide small but almost surely positive returns in case where global asset value is decreasing on short periods. There are multiple phenomenons that explain this potential decreasing : many risky agents can fall into Failure state in case of market crash situation or a sudden drop of prices on higly dependent crypto-assets ; portfolio threshold define in (8) is not realistically designed which causes agents to be stuck in Enhancedstate ; unexplicable event that occured onHost, which is uncertain and then is not modelisable and even less predictable.

• A second low-risk strategy, with same aim as first group, but instead trading onXRP/USD pair. More generally, we could consider multiple low-risk strategy groups where each focus on a non-volatile3 crypto-asset in order to preserve small returns on a long term basis. Note that this low-risk strategy does not imply zero-risk strategy, and these agents also needs some checks on their returns. We can only encourage Maintainerto actively monitor the ecosystem in action.

• A last group, referred as pump strategy. These agents are not much active compared to those in the two first groups, but they are seeking high returns analyzing eventual future

3Comparison done only inside portfolio assets. Indeed, compared to flat currencies, volatilities of crypto-assets are extremely high, and they can differ from one exchange to another.

(10)

Figure 6: Each strategy implements its own facilitator, as we assume that agents inside blocks are piloted according to a similar strategy. All of them are constantly linked to a VKB, and each facilitator has the ability to communicate directly with another.

pumps that could occur. They are by far the most risky agents living in the ecosystem, explaining why we introduced multiple agents that could change balance with low risks.

These pumps can be explained with multiple factors that oftenly occurs outside an exchange or a marketplace (news, ICOs, social media feeds, confidential information, ...), and these agents are exploiting these pumps to generate high profitability on global asset value.

Relationship between these strategy groups is detailled in Figure6. As previously explained, it is vital to establish concrete communications between strategy groups, especially with the last one.

A classical approach would be to obtain returns of every risky agents, and aggregate them to trigger a decision. This method is not only expensive in number of communications (bandwidth limitations and/or costs), but also inadequate on decentralization principle because each receiving agent has to compute a measure of risk, hence either having a definition inside its own structure (maintability issues), or contacting the VKB to frequently update its risk calculation. To tackle down such troubles, only facilitators has power to aggregate and broadcast this risk within ecosystem. Suppose that net crypto-asset value involved at timet in pump strategy is N AV(t), then we could easily define a risk measure as relative variation of N AV between times t and t0 decreasing below a certain valueξ:

ρN AV(t, t0) =N AV(t0)−N AV(t) N AV(t) ≤ξ

4 Conclusions

(11)

Figure 7: MeasureρN AV is computed each timeBTC agent ask a facilitator agent to find others agents that participate in calculation ofρN AV.

References

[1] Edmund H. Durfee and Jeffrey S. Rosenschein. Distributed problem solving and multi-agent systems. June, 1994.

[2] Marcel J. Schoppers Michael P. Georgeff, Amy L. Lansky. Reasoning and planning in dynamic domains: An experiment with a mobile robot. April 1987.

[3] K. L. Myers. User guide for the procedural reasoning system technical report. 1997.

[4] Zeng D. Sycara K., Decker K. Intelligent agents in portfolio management. Agent Technology : Foundations, Applications and Markets, pages 267–282, 1998.

[5] Bruno W.P. Hoelz Lucas O. Souza, Celia G. Ralha. Optimizing resource allocation with intel- ligent agents. May 2017.

[6] Kecheng Liu Yuan Luo, Darryl N. Davis. A multi-agent decision support system for stock trading. 02 2002.

[7] David C. Parkes and Bernardo A. Huberman. Multiagent cooperative search for portfolio selection. Games and Economic Behavior, 35:124–165, 2001.

[8] Tim Finin, Richard Fritzson, Donald P. McKay, and Robin Mcentire. Kqml as an agent communication language. pages 456–463, 01 1994.

Références

Documents relatifs

It seems impossible to solve a social optimum problem of the size of the french labor market because this one is furthermore constituted of 26 million job-seekers and that no

The principles of misunderstanding tolerance are similar to the fault-tolerance with error detection and system recovery. The implemented mechanisms track down the system

[r]

(1985) analysis, we show that contrary to the model of GJ (2003) there exist situations where competitors do not form collaborative links in order to increase the.. Considering

101 Given the roles of other stakeholders such as miners and developers, this renders Bitcoin governance to a strong governance framework for dFMIs similar to what is sometimes

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des

Given the difficulty to determine the fundamental value of artworks, we apply a right-tailed unit root test with forward recursive regressions (SADF test) to

Chapter 2 Hybrid framework for agreement in multi-agent systems This chapter presents our main results on the decentralized control design for multi- agent systems with