@bradcray quotes:
“Should a for loop on a dense 2D domain/array always iterate over the indices/elements in the same order (“to make the science of a code independent of the data structure order”), or should a domain map be able to define its own order (“for efficiency”) such that a RMO array would return in RMO, a CMO array in CMO, and an array using tiled memory or a space-filling curve would reveal that order. And similarly, if the 2D array is printed out, should that printout be independent of its memory layout, or reflect it? In practice, we’ve usually said “the same order” for productivity and postulated that there could be a .naturalOrder() iterator method if the user didn’t care about the order and wanted whatever serial ordering was faster.
"Should a for loop (or writeln) over a dense multidimensional domain reflect the storage order”, I believe that in the spec and in the code, the answer is “no” (and that this is the answer I like). But that it comes up in conversation just frequently enough with some people expressing hesitancy about it that I think it’s worthy of an actual conversation to put to bed. "
@bradcray
I believe what [the "if the ..." sentence] is saying is that some domain types, by nature, do not define a natural iteration order, where our associative domains are currently the key such example. And that other domain types do, like dense rectangular domains (where, as Michelle says, the order is lexicographic, or RMO).
vasslitvinov
commented
3 years ago
@bradcray quotes: “Should a for loop on a dense 2D domain/array always iterate over the indices/elements in the same order (“to make the science of a code independent of the data structure order”), or should a domain map be able to define its own order (“for efficiency”) such that a RMO array would return in RMO, a CMO array in CMO, and an array using tiled memory or a space-filling curve would reveal that order. And similarly, if the 2D array is printed out, should that printout be independent of its memory layout, or reflect it? In practice, we’ve usually said “the same order” for productivity and postulated that there could be a .naturalOrder() iterator method if the user didn’t care about the order and wanted whatever serial ordering was faster.
"Should a for loop (or writeln) over a dense multidimensional domain reflect the storage order”, I believe that in the spec and in the code, the answer is “no” (and that this is the answer I like). But that it comes up in conversation just frequently enough with some people expressing hesitancy about it that I think it’s worthy of an actual conversation to put to bed. "
@mstrout For rectangular domains, the for loop documentation, https://chapel-lang.org/docs/users-guide/base/forloops.html, strongly implies lexical order and so does the use of ranges in for loops (https://chapel-lang.org/docs/language/spec/ranges.html). However, neither of those pages have multi-dimensional examples. Here (https://chapel-lang.org/docs/language/spec/domains.html) I found "If the domain defines an iteration order of its indices, then the indices are visited in that order." It seems like first and last, if supported at all, should align with the default order or the order specified for the domain.
@bradcray I believe what [the "if the ..." sentence] is saying is that some domain types, by nature, do not define a natural iteration order, where our associative domains are currently the key such example. And that other domain types do, like dense rectangular domains (where, as Michelle says, the order is lexicographic, or RMO).
Tangentially related to the question about sparse first and last, https://github.com/chapel-lang/chapel/issues/17327.