4.5.10 Reduction Expressions

Term entry: reduction expression — expression that defines how to map or transform a collection of values into a new set of values, and then summarize the values by applying an operation to reduce the set to a single value

Reason: The intent is that the syntax matches as closely as possible array or container aggregate notation. Syntax that matches a loop_parameter_specification with the reverse reserved word would not be permitted in an array aggregate, so we disallow that here. 

Discussion: {AI22-0011-1} Accum_Type represents the result of the reduction (the accumulator type), and Value_Type represents the type of the input values to the reduction. 

Ramification: {AI22-0011-1} None of the parameters of a reducer subprogram can be aliased parameters, as such a parameter cannot be subtype conformant with these profiles. This means that it is not necessary to enforce any of the Legality Rules nor generate any of the checks associated with aliased parameters in for a reduction expression. 

Reason: {AI22-0011-1} For a reduction_attribute_reference with a value_sequence that does not have the reserved word parallel or has a prefix and the identifier of the reduction_attribute_reference is Reduce, Accum_Subtype the subtypes Accum_Type and Value_Subtype Value_Type can be different because only one logical thread of control is presumed so there is no need to combine multiple results. Indeed, in this case, they can be unrelated types. 

Reason: This is implied by the form of the profiles given above, but it is better to make it explicit. We would have to define the accessibility of the accumulator(s) among other rules to allow this, and it does not seem sufficiently useful for the complication. 

Implementation defined: The maximum number of chunks for a parallel reduction expression without a chunk_specification.

Ramification: {AI22-0011-1} {AI22-0047-1} This initialization follows the object initialization rules of an explicit object declaration. In particular, if the accumulator subtype is indefinite, then the tag, array bounds, or discriminants of the accumulator object are determined by its initial value as needed. Similarly, if the accumulator subtype is class-wide, the tag of the accumulator object is determined by its initial value. 

To be honest: {AI22-0047-1} In the case where Reducer is a function, “saving the result as the new value of the accumulator” has the semantics of an assignment of the function result into the accumulator, including associated finalization/adjustment as appropriate. 

To be honest: {AI22-0047-1} In the case where Reducer is a function, “with the result saved back in the overall accumulator” has the semantics of an assignment of the function result into the accumulator, including associated finalization/adjustment as appropriate. 

Implementation Note: {AI12-0262-1} For a reduction_attribute_reference that has a value_sequence without the reserved word parallel or a prefix where the identifier of the reduction_attribute_designator is Reduce (see below), generally the compiler can still choose to execute the reduction in parallel, presuming doing so would not change the results. However sequential execution is necessary if the subtypes of the parameters of Reducer do not statically match, since there is no subprogram identified in the construct that could be used for combining the results in parallel.

Discussion: {AI12-0262-1} We say the calls to Reducer that combine the results of parallel execution are sequentially ordered in increasing order because certain reductions, such as vector concatenation, can be non-commutative (but still associative) operations. In order to return a deterministic result for parallel execution that is consistent with sequential execution, we need to specify an order for the iteration, and for the combination of results from the logical threads of control. It is also necessary that combining calls to Reducer are issued sequentially with respect to each other, which may require extra synchronization if the calls to Reducer are being executed by different logical threads of control. 

Reason: In a sequential reduction expression, the reducer subprogram is called in a left-to-right order, whereas in a parallel reduction expression, the reducer subprogram is called in an order that depends on the number of logical threads of control that execute the reduction and on the elements/components given to each chunk. If the reducer is associative, this order does not matter, but in other cases, very different results are possible. While one can specify the maximum number of chunks, the actual number of chunks is unspecified. Similarly, the split of elements has only weak requirements. Thus, to get a consistent and portable result, an associative reducer is required for a parallel reduction. We define this as a Bounded (Run-Time) Errors to provide a stern warning about the required nature of the reducer subprogram and to let compilers detect the problem when possible. 

To be honest: In this rule, “equal” means semantically equal. We don't care if the bit patterns differ but that the results mean the same thing. In particular, if the primitive equal is user-defined, that equality would be the one used to determine if this rule is violated. 

{AI12-0005-1} {AI12-0242-1} {AI12-0262-1} {AI12-0348-1} Reduction expressions and the associated attributes are new. 

{AI22-0011-1} Corrigendum: Added wording to make it clear that values are converted to the appropriate subtypes. The original Ada 2022 wording did not say this, and in particular for the initialization of the accumulator seemed to imply that there was no conversion (and checks), since we always say that explicitly. If an implementation did not make any check when initializing the accumulator, a program that worked in original Ada 2022 now might raise Constraint_Error. This seems unlikely (known implementations do make a check for the initialization; even if they didn't, subsequent usage probably would would make a check), so such a case probably won't occur in practice.

{AI22-0069-1} Corrigendum:Added wording to define how empty subsequences are handled for parallel reductions. This was incorrectly defined in original Ada 2022; an implementation following the rules as stated would produce nonsense results. We are not aware of any implementations of parallel reduction for original Ada 2022, and the results were nonsense and dependent on how chunks were selected, so it seems highly unlikely that any code depends on the incorrect definition. (Note that non-parallel reductions were correctly defined, and are unchanged.) 

{AI22-0081-1} Corrigendum: The ability to use named notation in uses of reduction attributes is new.

{AI22-0011-1} Corrigendum:Explicitly stated that Accum_Subtype and Value_Subtype cannot be anonymous access types. It is already illegal for these subtypes to be anonymous access types (as the profiles only allow named subtypes, and anonymous access types cannot be named, but this is better explicitly stated.

{AI22-0011-1} Corrigendum:Renamed Accum_Type to Accum_Subtype, and Value_Type to Value_Subtype, since for most purposes these are subtypes. And it makes more sense to say “type of Accum_Subtype” that it does to say “subtype Accum_Type”.