Find the 'source turtle' of an item in a list - netlogo

Question

I would like to track the path of a wallet stolen by a thief. The model should create a network of thieves, each of them with their own bags where they put the stolen objects (I am setting this objects - wallets - as self).
Let suppose that thief1 has in his own bag [wallet1 wallet2 wallet4] and his neighbour has [wallet1 wallet3] as wallet1 was added in his own bag.
If the neighbour with bag [wallet1 wallet3] wants to pick randomly one of the two items to return to the police, for example wallet1 (and this can be done using [let picked_wallet one-of turtle-set my-bag]), how can I add a 'tag' or something that can tell me that the first thief to stole that wallet was the thief1?
globals [this-wallet]
breed[thieves thief]
thieves-own [my-bag wallet-id]
to setup
clear-all
create-thieves 5
ask thieves [ set my-bag [] create-links-to other thieves ]
ask one-of thieves [ set this-wallet self set my-bag fput self my-bag ask link-neighbors [set my-bag fput this-wallet my-bag print "Neighbours " show my-bag ]]
ask one-of thieves [ set this-wallet self set my-bag fput self my-bag ask link-neighbors [set my-bag fput this-wallet my-bag print "Neighbours " show my-bag ]]
ask thieves [show link-neighbors show my-bag]
reset-ticks
end

Answer 1

In response to your comment on my last answer, here's a new answer.
Well, a virus problem is different from a wallet problem and needs different data structures.
Still, viral transmission can be modeled as a series of transactions, so the idea of using a global master list of transactions to keep track of what has gone on is still a workable approach.
You COULD also keep a list on each agent of who they got a virus from and when, but it would be redundant with a single master list -- you can simply filter the master list of transactions by agent to see exactly the same information as what you are trying to keep in many lists at the agent level. I'm not sure why you do not like that approach.
Keeping one list is much cleaner than keeping many lists. Any question you could ask agents-with-lists you could also answer by searching the global list.
It would make sense to have a little redundancy for viewing what is going on and for simplifying the ASK command you will use to spread the virus -- so you could store at the agent level whether the agent is currently-infected? and color-code infected agents to tell them apart from never-infected agents and fully-recovered? agents and dead? agents.
Even that could be reduced to a single status variable with legitimate values of "healthy" "infected" and "recovered" and a single is-immune-now? flag. That would be enough to figure out who is contagious, who is infected, who could possibly become infected, who has recovered, who has died, etc.
Of course, if you are playing epidemiologist and trying to track down where the infection came from ( "patient zero") you COULD add a variable showing for each person WHO they got infected BY and when and write some long recursive code to trace back step by step where that linked-list started. OR, you could just get the same answer in a simple single filtering pass of the master list of who infected whom and when.
Maybe doing this the easy way is "cheating" and you want to play doctor instead of God and you want to show how it could possibly be tracked back one step at a time? Or you want to show how an epidemiologist might go to a lot of effort to build a "tree" diagram showing where the infection started and how it spread down different branches?
That's an INTERESTING problem but it is not the question you asked.
If you want to find the ultimate-source-turtle for an item in a list, you need to modify your data-structure. One way ( the hard way ) to do that would be to store more information in each turtle's list -- so at the time the virus is added to the list you ALSO add a timestamp and a source-turtle. Possibly you could store this information as triplets in a list such as [ source-agent-id tick-acquired virus-type ] and so each agent would have a list of such triplet-lists. That could work. That's one way to do it.
That would require that you add some complexity to the process that puts the virus on their list. It would have to build a list of the 3 items and put that list onto the target my-list of any agent it infected. ( In your case the virus seems to be 100% contagious and anyone with it gives it to everyone else! )
So your ASK-TURTLES logic would be a little bit more complicated. You could manage the complexity by having little to-report routines that packed the triplet-list or unpacked it.
OR, with fewer lists to manage, you could have your ASK-TURTLES logic store a series of transactions, that you could code as 4-item lists: [ source-id target-id virus-type tick-infected ] and store that in a master list-of-lists in a global variable. You still might want to set the target-turtle's variables of "status" and "immune-now?" at the time you are infecting the next agent to simplify identifying which turtles are contagious and which turtles are immune to simplify the next go step where you would ask turtles who are contagious to infect turtles who are not immune and are within a given radius, etc.

Answer 2

You asked
how can I add a 'tag' or something that can tell me that the first
thief to stole that wallet was the thief1?
I'm not clear about what operation corresponds to "stealing a wallet". Is the agent doing the stealing the one who puts the wallet on someone's list? Or the one whose list it gets put on?
In your example you have two different people with "wallet1" on their list, so I'm also not clear about who "has" the wallet. How can one wallet be two places at once? In fact it's more than two places, when it's put on one thieves list, it's put on every thieve's list. What is that operation supposed to represent? Is that "stealing"?
Are you trying to figure out which of the many copies of wallet1 got put on any agent's list first in time? Of course that's a little hard because agent sets are always processed in a random order, so the code you show gives no clue to who got it first.
What I'm suggesting is that the data-structure you have doesn't seem to do a good job of representing real-world operations, and if this doesn't confuse the current question of who got the wallet put on their list first, which is what I think you're asking, it will surely confuse other questions down the road. The operation you show for updating the lists makes it impossible to determine which thief got it first.
It certainly confuses me. I think your coding would be much easier if there was only ever one copy of wallet1 in existence, and it was only on one agent's list at a time, and the agent's list was only one entry long, and you had a "steal-wallet" procedure that removed a wallet from one agent's list and put it on exactly one different agent's list. Then it would be clear what time that happened.
Or are these lists supposed to represent knowledge one agent has about the existence of the wallet? Or do they represent all wallets that ever existed owned by anyone over all historical time, in which case the "same" wallet might appear many different times, each time representing a different owner, and even the same wallet and the same owner might be stolen and stolen back multiple times so even that pair of facts (wallet-id and new-owner) would not be unique.
For one thing, if everyone is going to end up with identical lists, then find some place to put the list once and be done with it -- don't give everyone a copy when one copy will do. The list doesn't even need to be owned by anyone -- it can simply be a global variable. That would simplify a lot. Then you only have one wallet, and each time it changes owner you can make an entry in the master-list.
What should the entry have in it? Certainly not the wallet itself, because that CAN be passed around. Probably you need a sublist that describes the transaction that just took place, so you would need a sublist containing [wallet-id, last-owner-id, current-owner-id, time-it-changed-hands] as the entries in the master global list.
From that you could at least conceptually be able to reconstruct who had the list first, second, third, .. or last, who has it now, anything you wanted. Or if you always did "lput" to put the latest event as the last item on the list, then you wouldn't even need the time-stamp, unless you lose information by sorting the list, because the first owner would be the first entry on the list that had that wallet-id. Problem solved, in concept. Still you might want to sort the list someday, so having the timestamp on it would allow you to recover the order later if you wanted to.
In conclusion of all that discussion, my suggestion to finding out who had wallet1 first would be this:
* get rid of the my-lists on every agent entirely.
Work with a single list defined as a global.
treat wallets as if they are real and only have one copy of a wallet at any one time.
define procedures "steal-wallet", "create-wallet" and "destroy-wallet" that move the wallet from one owner to another, and record the transaction as a sublist of 4 facts in the master list. The master list would be a list of lists then.
the master list might be named "transactions" because that's what it records.
then, conceptually, you would have all the information you need to answer any question about the life-history of a wallet or the life-history of a thief. You wouldn't have to maintain 20 different copies of the same information.
and it would be easy to look at all the thieves and see which one had the wallet, without needing to look at the transaction list. ( although, that information would correspond to the last entry in the transaction list about that wallet.)
Or -- maybe I totally misunderstand what these lists represent.
Passing the ball ( or wallet ) back to you.