>>>>> "Charles" == Charles <[email protected]> writes:
Charles> A question about design. I've updated my update to the matrix Charles> extension by allowing the new map reporter primitive to take Charles> multiple matrices just as the NetLogo map primitive can take Charles> multiple lists. I've also added a map-in-place command Charles> primitive that replaces its single matrix argument with the Charles> new matrix. It would be trivial to allow map-in-place to take Charles> multiple matrices and to replace the first one in the list. Charles> But this makes me uneasy. It seems to me to be courting Charles> confusion and errors, and doing things in place seems out of Charles> keeping with most NetLogo primitives. Charles> Any thoughts? In general, I think it's better not to encourage too much use of in-place mutation. The norm in NetLogo is immutable data structures (strings, lists, agentsets [non-special agentsets immutable except by death]). It's true that the array, table, and matrix extensions all provide mutable data types. But at least in the array and table cases, this is mainly an accident of history. At the time we made them, Java didn't offer immutable data structures that offered efficient copy-and-update operations via structural sharing. But we're using Scala now, and Scala does offer that. Therefore, if I were building the table extension today, I would make it immutable, and I wouldn't bother building the array extension today at all, since NetLogo's lists are immutable yet efficiently updatable (thanks to scala.collection.immutable.Vector). Whether it would be possible to implement a new matrix extension that didn't offer any in-place operations at all, yet was still fast "enough", I don't know -- partly because "enough" is subjective. But anyway, you're asking about the matrix extension we actually have, not some theoretical one. In the existing extension, I would argue that an operation that performs in-place update might only worth offering if it is asymptotically more efficient than the alternative based on copying? By such a rule, we would keep `matrix:set`, but we would not add the primitive you propose above, since both it and the regular `matrix:map` primitive you already built are O(n) in the number of matrix cells. -- Seth Tisue | Northwestern University | http://tisue.net developer, NetLogo: http://ccl.northwestern.edu/netlogo/ -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
