Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support transferring and cloning of agents between models #69

Open
qiemem opened this issue May 15, 2016 · 6 comments
Open

Support transferring and cloning of agents between models #69

qiemem opened this issue May 15, 2016 · 6 comments
Milestone

Comments

@qiemem
Copy link
Member

qiemem commented May 15, 2016

Turtles:

  • ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>
  • Can transfer/clone (kill in one, create in another) between models with the same turtle/breed variable names. That is, can copy if:
    • Does a breed with the same name as the turtle's breed exist in the target model?
    • Take all the names of the turtle's turtle and breed vars. Do variables with the same names exist in the target model?
    • Does the turtle's shape exist in the target model? (we could just default shape if not)
    • If yes to these questions, can transfer.
  • Variables are matched up by name, except for position
  • Position is tough since the worlds will have different dimensions, and even if they have the same dimensions, it's unlikely that the user will want the turtle's position to be preserved. Right now, I think the turtle should just appear at 0,0, and there should be an optional command block that it runs upon creation that receives xcor as ?1 and ycor as ?2.

Patches:

  • Clone only

Links:

  • Not sure
@arthurhjorth
Copy link
Member

I like this idea. I think we tried solving it a few years ago with agents as first order LevelSpace objects. I'd really like to see some implementation of it. My thoughts:

ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>

This assumes a Controller type model that moves agents between child mdoels. We should allow for moving from the current model to child models too. See below for a suggested solution.

Can transfer/clone (kill in one, create in another) between models with the same turtle/breed variable names.

It's possible that people want concurrent representations in different models of the same agent. I think we should not kill, but only clone. It's easy enough for people to kill a turtle in NetLogo anyway.

My suggestion would therefore be to split into a command a reporter. The reporter reports a TPL-set. The command takes one and clones.

Speaking of which...

That is, can copy if: [.....]

I'd love this to be more flexible. Can we add a variable to agents that isn't declared in -own called variables or something? That way we can clone all data that exists in the model, and put the rest in a key-value map? If that is possible, we can do stuff with an agent in model a, clone it to model b and have it do stuff, and then send it back to model a with some updated information based on what happened in model b, but without losing information.

Position is tough [...]

I don't think it is. I think your suggestion addresses everything that should be addressed, and I agree 100%.

@arthurhjorth
Copy link
Member

arthurhjorth commented May 15, 2016

Something like

let ls-agentset ls:agent-set turtles with [color = red]
ls:clone-agents <model-id> ls-agentset [ command-block ]

I am trying to wrap my head around potential ClassLoader issues with passing this to other LevelSpace extension objects. Maybe I shouldn't?

edit: no wait, I definitely should. We will have ClassLoader issues if we want to let people clone to other LS extension objects, i.e. across more than one generation, or even within generation depending on the structure of the model ecology. So that's something to consider too.

@qiemem
Copy link
Member Author

qiemem commented May 15, 2016

I was hoping to keep it all in one procedure exactly to avoid dealing with custom levelspace objects so we don't have to deal with classloader issues.

How about an ls:self to allow cloning and transferring with the parent? e.g.

ls:clone-agents ls:self [turtles with [ color = red]] child-model [ initialization ]

@qiemem
Copy link
Member Author

qiemem commented May 15, 2016

Map thing:

Let's do compatible models first. It's a strict problem. We'll want that to work as described no matter what. The map thing is pretty tough. We can add turtle variables, so we have to store in the extension itself. But then you could end up with more than one map per turtle when having >2 levels.

@SethTisue
Copy link
Collaborator

SethTisue commented May 26, 2016

I'm picturing https://en.wikipedia.org/wiki/Wood_between_the_Worlds . disoriented turtles waking up with rings taped to their shells

@qiemem qiemem added this to the post-hexy milestone Jul 24, 2016
@arthurhjorth
Copy link
Member

I don't know if @SethTisue meant it (mostly?) as a joke, but I actually really like that analogy. I also like the post-hexy milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants