AgentSet.setBreed() resets agent position and shape--is it intentional?

[bennlich]

Came across this while working on a DLA model to add to the sample models. When doing:

someBreed.setBreed(someAgent)

someAgent winds up getting most of its innards reset (see https://github.com/backspaces/agentscript/blob/master/src/agentset.coffee#L108-L109).

Seems like those two lines could just be deleted, but maybe I am missing their intended use?

[backspaces]

Yeah, breeds are difficult, especially when changing between breeds. The semantics aren't clear. For example, should they keep variables that are not in the new breed? Should it act like simply creating a new instance of the breed, setting any variables that are in the new breed and the old breed?

For example, breeds often have different shapes/colors. If the old breed had a shape, it needs to be removed and be the default for the new breed, I think. Which of the old values should be be kept? Totally agree x,y should be kept.

But clearly this is a bug that shows I couldn't come up with good semantics for changing breeds.

[bennlich]

should they keep variables that are not in the new breed?

Maybe they should. We haven't really been using the turtles own syntax in our models. I think maybe it doesn't make much sense in javascript-land, where objects are very flexible? At least, not unless we switch to using all typed-arrays. What do you think?

(By the way, I posted this to slack a while ago, but I dunno if you saw it: http://codereview.stackexchange.com/questions/28344/should-i-put-default-values-of-attributes-on-the-prototype-to-save-space/28360#28360.)

For example, breeds often have different shapes/colors. If the old breed had a shape, it needs to be removed and be the default for the new breed, I think.

Yes, definitely shape and color should be updated if the new breed has a default shape and color. Can we safely:

1. update the agent's phenotype to match that of the new breed
2. leave all an agent's other attributes unchanged, even if the new breed doesn't own them
3. add new variables to the agent if they have been set as breed defaults

?

[backspaces]

Yup, sounds very understandable too. Easier to explain. Being Javascript-y is a Good Thing and I think this is.

Would you do it?

Re defaults: If I had to say what the toughest issues in AS, breeds and defaults would be at the head of the list. I had a thought about defaults: they are mainly renderer related, so if we split agents into the strictly agent data and a reference to its renderer, possibly as a sub/super class or simply a property, then we'd have a win-win: sane default architecture with a nice refactoring that we've discussed before.

BTW: I'm thinking about the future of AS after having taken a break for the mooc and several "real life" family issues.

One thing for sure, after using JSPM & Babel .. and the browsers having over 50% es6 coverage, I would vastly prefer to use es6. I hate to admit it, I find CS a bit annoying at this point, sigh.

But architecturally, I like your ideas of a top-down approach: document first, KISS, great demo page maybe with a REPL/IDE. But maybe more important, how to best integrate with other systems like SimTable & Leaflet. Possibly as a "modeling plugin"? Definitely separate rendering from data.

But really, the bigger issue is one I learned long before in Silly Valley: never begin a project without at least two engineers and one hungry customer. Me being a loner was a loser. And not being clear on how to integrate into SimTable or Redfish or some other use base was silly too.

Any ideas?

On Sat, Oct 3, 2015 at 10:35 PM, Benny Lichtner [email protected] wrote:

should they keep variables that are not in the new breed?

Maybe they should. We haven't really been using the turtles own syntax in our models. I think maybe it doesn't make much sense in javascript-land, where objects are very flexible? At least, not unless we switch to using all typed-arrays. What do you think?

(By the way, I posted this to slack a while ago, but I dunno if you saw it: http://codereview.stackexchange.com/questions/28344/should-i-put-default-values-of-attributes-on-the-prototype-to-save-space/28360#28360. )

For example, breeds often have different shapes/colors. If the old breed had a shape, it needs to be removed and be the default for the new breed, I think.

Yes, definitely shape and color should be updated if the new breed has a default shape and color. Can we safely:

1. update the agent's phenotype to match that of the new breed
2. leave all an agent's other attributes unchanged, even if the new breed doesn't own them
3. add new variables to the agent if they have been set as breed defaults

?

— Reply to this email directly or view it on GitHub https://github.com/backspaces/agentscript/issues/93#issuecomment-145317477 .

[bennlich]

See code example at bottom of here--in netlogo, changing an agent's breed updates that agent's shape.

Would you do it?

Yes!

I had a thought about defaults: they are mainly renderer related, so if we split agents into the strictly agent data and a reference to its renderer, possibly as a sub/super class or simply a property, then we'd have a win-win: sane default architecture with a nice refactoring that we've discussed before.

Nice.

But really, the bigger issue is one I learned long before in Silly Valley: never begin a project without at least two engineers and one hungry customer. Me being a loner was a loser. And not being clear on how to integrate into SimTable or Redfish or some other use base was silly too.

Yeah--I hate working alone on programming projects. Definitely going to try to avoid that in the future. Way too much is lost without a collaborator--someone to think and make decisions with. Sorry you had to work solo for most of this huge undertaking :-/

Any ideas?

If I can find the time, I'll probably do a little cleanup here and there. I'm heading back to NM soon, so maybe we could meet in person to talk about a minimal way of accomplishing what you mentioned above:

document first, KISS, great demo page maybe with a REPL/IDE

If it sounded fun to you, we could also devote some time to spreading the word (i.e. finding that "one user" you mentioned above, or several). Speaking to folks at the European Conference on Complex Systems was somewhat inspiring--Agentscript definitely seems like it could be a useful tool for a lot of people in the ABM world.

My current plan is to spend a lot of time on grad school applications in the coming months, but after that, let's meet up?

[backspaces]

Lets do get together when you're here next. Getting ready for grad school is fun and kinda scary!

One idea I had was to refactor via es6, converting from CoffeeScript.

Modules made a huge difference in my webgl mooc assignments. Its a bit odd to see all the