19268, "vasslitvinov", "Should 'rectangular' mean nonsparse for a domain?", "20220218T04: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 nonsparse 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 rereview, we liked this proposal, however we also see the merit in the current classification. Therefore...
Counterproposal
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 counterproposal is TO NAME the category of rectangular nonsparse. The name we have for it currently is regular
, which is not intuitive.