igorcadelima commented 7 years ago

Hi, everyone!

I was going through the second part of the coordination tutorial and I'm pretty sure I've found a problem. The step 4 shows a picture of the output that the given code produces and states that this output should be similar to the one produced in the previous part of the tutorial. However, the result is actually pretty different!

The problem is that each agent may, unpredictably, successfully bid 2 times. This wasn't the case in part 1. As can be seen in the picture, Alice bid twice.

The problem seems to happen because some agents perceive task for the first time after running becomes true. Here is the output I got by adding a plan for when running is false:

[giacomo] I bid for no_task while auction wasn't running Received bid 76.2237462016476 from giacomo for flight_ticket(paris,athens,15/12/2015) Received bid 92.14937592883264 from francois for flight_ticket(paris,athens,15/12/2015) Received bid 34.256298152191476 from francois for flight_ticket(paris,athens,15/12/2015) [maria] I bid for no_task while auction wasn't running Received bid 60.33093416377695 from maria for flight_ticket(paris,athens,15/12/2015) Received bid 25.22431555802851 from alice for flight_ticket(paris,athens,15/12/2015) [alice] I Won! [bob] Winner for flight_ticket(paris,athens,15/12/2015) is alice with 25.22431555802851

Note also that the output shows that there were only 7 belief additions in total (wrt to the task property), instead of 8.

For the tutorial, one possible easy fix would be to perform the following changes in AuctionArtifact artefact:

//    @OPERATION
    public void init()  {
        // observable properties
        defineObsProperty("running",     false);
//        defineObsProperty("task",        "no_task");
        defineObsProperty("best_bid",    Double.MAX_VALUE);
        defineObsProperty("winner",      new Atom(currentWinner)); // Atom is a Jason type
    }

    @OPERATION
    public void start(String task)  {
        if (getObsProperty("running").booleanValue())
            failed("The protocol is already running and so you cannot start it!");

        defineObsProperty("task",        task);
//        getObsProperty("task").updateValue(task);
        getObsProperty("running").updateValue(true);
    }

Cheers.

jomifred commented 7 years ago

Thanks Igor for remarking this issue and providing a solution! We added it in the website.

igorcadelima commented 7 years ago

No worries, @jomifred! I'm glad I could be of assistance :)

I'm sorry to bother you, but could you, please, tell me why this problem was happening? This doesn't seem to be a problem with the tutorial only, but a general problem. The previous code seemed ok and I expected that there would always be 8 perceptions of the task property, 4 when running was true and 4 when it was false.

jomifred commented 7 years ago

We have to take into account that everything is asynchronous and concurrent. So, I guess, when one of the agents has get a slot of time to run, the value of running is already true… or, when the agent has focused on the art, the auction is already running and it lost the initial value “no_task”….

On 23 de dez de 2016, at 11:14, Igor C. A. de Lima notifications@github.com wrote:

No worries, @jomifred! I'm glad I could be assistance :)

I'm sorry to bother you, but could you, please, tell me why this problem was happening? This doesn't seem to be a problem with the tutorial only, but a general problem. The previous code seemed ok and I expected that there would always be 8 perceptions of the task property, 4 when running was true and 4 when it was false.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

-- Jomi Fred Hubner Federal University of Santa Catarina Department of Automation and Systems Engineering PO Box 476, Florianópolis, SC 88040-900 Brazil http://jomi.das.ufsc.br

jomifred commented 7 years ago

If a better synchronized execution is required, one idea is auctioneer to run a .wait(1000) before the operation start. So that all agents are ready when the auction starts. I guess that in this case 8 perceptions will occur.

aricci303 commented 7 years ago

Actually Igor pointed out an issue which - as far as my experience and knowledge - is more than a bug, it is a known situation related to both concurrency (as Jomi pointed out) and the implementation of reasoning cycle. I would see this post as an opportunity to talk about it.

Premises about the operational semantics:

percepts coming from the environment are enqueued and processed one by one each reasoning cycle
a percept coming from a change of the observable state of an artifact (given e.g. by the execution of an operation that updated one or multiple obs props) causes in Jason the atomic update of the belief base (BB) in the sense stage
the update of the BB causes the generation of one or multiple internal events - belief updates - that are enqueued and processed one by one in the plan stage (in multiple cycles).

Given this enqueuing strategy, in a plan:

+Event : Context <- Body

the Event could refer to a state of belief base which could be different from the state which is considered in Context. The Event is generated when updating the bel base. Context is evaluated when the internal event is actually processed, after having being enqueued. In the meantime the BB could have been changed. This is I guess what happens in the example:

+task(D)[artifact_id(AId)] : running(true)[artifact_id(AId)] <- bid(math.random * 100 + 10)[artifact_id(AId)].

When the agent perceives in the sense stage:

task("no_task")

it is true that it perceives also:

running(false)

(the set of obs props changes are perceived atomically). The corresponding belief update event:

+task("no_task")

is enqueued and fetched not in the same cycle. Then it happens that when it is fetched, the agent has already perceived also a further task(...) and running(true) percepts. Consequently, the plan:

+task(D)[artifact_id(AId)] : running(true)

is considered relevant and applicable. To avoid this conceptual bug one should keep in mind this level of asynchrony when designing plans, so that the Context condition should not be referred to the state of the BB when the corresponding percept was perceived.

Since this situation is quite frequent, I'm wondering if it could be interesting to consider an extension of the basic AgentSpeak(L) plan model where the programmer has the possibility to (optionally) specify also a contextual condition related to the cycle / BB state when the event has generated / the percept has been fetched (C1 in the following):

+E ∧ C1 : C2 <- B

This would call to evaluate C1 (and keep track of) when the event is generated.

aricci303 commented 7 years ago

============ I posted this on github some days ago, but I noticed that I haven't received it as subscriber...so, to be sure, I re-send it now as an email.

Actually Igor pointed out an issue which - as far as my experience and knowledge - is more than a bug, it is a known situation related to both concurrency (as Jomi pointed out) and the implementation of reasoning cycle. I would see this post as an opportunity to talk about it.

Premises about the operational semantics:

• percepts coming from the environment are enqueued and processed one by one each reasoning cycle
• a percept coming from a change of the observable state of an artifact (given e.g. by the execution of an operation that updated one or multiple obs props) causes in Jason the atomic update of the belief base (BB) in the sense stage
• the update of the BB causes the generation of one or multiple internal events - belief updates - that are enqueued and processed one by one in the plan stage (in multiple cycles).

Given this enqueuing strategy, in a plan:

+Event : Context <- Body

the Event could refer to a state of belief base which could be different from the state which is considered in Context. The Event is generated when updating the bel base. Context is evaluated when the internal event is actually processed, after having being enqueued. In the meantime the BB could have been changed. This is I guess what happens in the example:

+task(D)[artifact_id(AId)] : running(true)[artifact_id(AId)] <- bid(math.random * 100 + 10)[artifact_id(AId)].

When the agent perceives in the sense stage:

task("no_task")

it is true that it perceives also:

running(false)

(the set of obs props changes are perceived atomically). The corresponding belief update event:

+task("no_task")

is enqueued and fetched not in the same cycle. Then it happens that when it is fetched, the agent has already perceived also a further task(...) and running(true) percepts. Consequently, the plan:

+task(D)[artifact_id(AId)] : running(true)

is considered relevant and applicable. To avoid this conceptual bug one should keep in mind this level of asynchrony when designing plans, so that the Context condition should not be referred to the state of the BB when the corresponding percept was perceived.

Since this situation is quite frequent, I'm wondering if it could be interesting to consider an extension of the basic AgentSpeak(L) plan model where the programmer has the possibility to (optionally) specify also a contextual condition related to the cycle / BB state when the event has generated / the percept has been fetched (C1 in the following):

+E ∧ C1 : C2 <- B

This would call to evaluate C1 (and keep track of) when the event is generated.

On 23 Dec 2016, at 14:34, Jomi F. Hubner notifications@github.com wrote:

If a better synchronized execution is required, one idea is auctioneer to run a .wait(1000) before the operation start. So that all agents are ready when the auction starts. I guess that in this case 8 perceptions will occur.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jacamo-lang/jacamo/issues/4#issuecomment-268990404, or mute the thread https://github.com/notifications/unsubscribe-auth/ALNCMjafiO7QIPl8g-Z6jMyVoHj_e0ENks5rK83zgaJpZM4LUbkC.

jacamo-lang / jacamo

Problem with belief addition in the coordination tutorial #4

============ I posted this on github some days ago, but I noticed that I haven't received it as subscriber...so, to be sure, I re-send it now as an email.