As a follow-up to Seth's remark about one-of ... with [...], I would like to point out that the NetLogo compiler optimizes this form so that it doesn't actually search every path. Instead it searches the patches in random order until it finds one that meets the condition, and returns that. The following forms are so optimized:
- one-of ... with [...] - count ... with [...] - other ... with [...] - with other ... [...] - any other ... - any other with [...] - count other ... - count other ... with [...] - any ... with [...] - count ... with [...] (when checking whether the count is equal to or greater than 0, replaces with any ... with [...] / not any ... with [...]) These optimizations occur only once, so ... with [...] with [...] does not get optimized into a single with. Consequently one-of other ... with [...] is markedly slower than one-of ... with [...], which isn't intuitive. Bryan has opened a ticket for this <https://github.com/NetLogo/NetLogo/issues/679>. All of that is to say that the problem that Seth is pointing out is different than imagined. In some ways it is better because in a number of cases we don't need to call the coder's attention to the fact that one-of ... with [...] is a problematic exhaustive search. However, that opens a very different conceptual "problem", which is that the compiler can change the best-case asymptotic complexity of a user's code by selectively making agentset operations lazy. Laziness isn't something we typically talk about in NetLogo, but it's something that could potentially change the meaning of a user's code if they are using a reporter with side effects. -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
