19268, "vasslitvinov", "Should 'rectangular' mean non-sparse for a domain?", "2022-02-18T04:00:36Z"
This issue asks whether the concept rectangular domains should include sparse domains.
This decision affects the Domains chapter of the language spec and the predicates domain.isRectangular() and array.isRectangular() . The documentation needs to be clear about this topic.
Background
The current language specification defines here the following concepts:
-
A domain is exactly one of the following:
- base rectangular domain
- simple rectangular subdomain
- sparse rectangular subdomain
- base associative domain
- simple associative subdomain
- sparse associative subdomain (currently not implemented)
-
Broader domain categories are:
- regular: a compact representation of a rectangular index space
i.e. rectangular non-sparse domains+subdomains - irregular: all others
i.e. associative domains+subdomains and sparse subdomains
- regular: a compact representation of a rectangular index space
In practice we typically use a simpler classification instead, where a domain is exactly one of:
- rectangular (excludes sparse, so the same as "regular")
- associative (excludes sparse)
- sparse (includes only sparse rectangular, as we do not have sparse associative)
Associative and sparse domains are collectively called "irregular".
This simpler classification is reflected in the current behavior of the methods .isRectangular() .isAssociative() .isSparse() .isIrregular() on domains and arrays.
Proposal
This issue proposes to exclude sparse subdomains from the category of rectangular domains. Then, eliminate the regular category as an unnecessary synonim for "rectangular".
This proposal takes the view that a sparse rectangular domain is not really rectangular.
The key benefit of this proposal is a simpler, clearer classification of domains -- the one we typically use in practice, see above.
If the user wants to distinguish between sparse subdomains of rectangular vs. associative domains when we have the latter, they can query the sparse domain's parent. We can also define the methods .isSparseRectangular() and isSparseAssociative() if desired.
In today's domain module re-review, we liked this proposal, however we also see the merit in the current classification. Therefore...
Counter-proposal
DO include sparse rectangular subdomains in the rectangular category. This reflects the view that sparse rectangular subdomains DO define a rectangular iteration space, in their own way. Also, this follows the lead of Matlab.
The main challenge with this counter-proposal is TO NAME the category of rectangular non-sparse. The name we have for it currently is regular, which is not intuitive.