Ordering of ls:ask

[arthurhjorth]

I forgot. Did we decide to unorder ls:ask? I think we should. In the circumstances where people want to order it, they can sort ls:models just like they would have to do with turtles, and if they want to save "special models" that should be treated uniquely, they can save them in variables, like they would do with turtles.

This would need to be changed in the code though, so our documentation aligns with the paper. :)

[arthurhjorth]

Oh, now it is finally coming back to me. So yeah, we lose paralellization. Can we introduce a ls:ask-ordered and randomize ls:ask? Did we already decide on that?

[arthurhjorth]

Btw, this is a good example of primitive design - we could discuss it in the workshop later today.

[arthurhjorth]

closed after conversation with @qiemem

[qiemem]

Just to make sure the information is preserved, there are a couple reasons why ls:ask and ls:of work the way they do. First, note that ls:ask is actually non-deterministic: when asking multiple models, it will typically run things in parallel. ls:of always returns ordered results, but executes in a non-deterministic order as well. That said, when they don't run parallel, execution happens in order. Okay, with that out of the way, the reasons it works the way it does:

• ls:of returns results in the order of the list so that you can have many models run a reporter in parallel and still be able to match up the results with the model. If we made ls:of return in random order, we would lose parallelism in cases where we want to know which model returned which result.
• The user can't actually tell, in the vast majority of cases, what order ls:ask and ls:of execute in. Randomness matters in normal ask and of because agents all share a world state that they can each modify directly. Since child models cannot directly affect the parent model, the order the models execute can't actually impact the behavior of the model (note I'm talking about order of execution here; order of ls:of results still can). The only way you can have the order of execution affect anything is through file IO.
• ls:ask and ls:of run on lists, not sets. From a semantics perspective (rather than teleological), the randomness of ask and of derives from the randomness of agentsets. Thus, the right way to fix this would be to implement "model sets". But this would entail reimplementing the entirety of the agentset querying API, which just leads to a bloated API and lots of duplicated work between core and LS. It would be super cool if we could inherit from api.AgentSet or something and have everything just work, but we need to take CodeBlocks, not command or reporter blocks, since we need to compile the blocks in a different context.

I think that's everything. I'll update this issue if I remember any other considerations.