Thanks Seth. Our messages overlapped. I agree, and will delete the map-in-place option.
On Friday, February 21, 2014 11:20:48 AM UTC-5, Seth Tisue wrote: > > >>>>> "Charles" == Charles <[email protected] <javascript:>> 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.
