APL 2020 ⍴ reshape operator: element-count mismatch handling across interpreters

Question

APL 2020 extended the built-in reshape operator ⍴ with negative dimensions for inferred size and zero dimensions for empty arrays of a given rank. The unresolved decision concerns what happens when the source array's element count does not equal the product of the target shape dimensions.

Version assumption: APL 2020 or later. Documentation describes the mismatch policy as implementation-dependent. Some interpreters raise an error, while others silently truncate or pad with zeros. Older versions may also truncate or pad, so code that relies on one outcome can behave differently across runtimes.

This is a design question with no reported incident. The goal is to determine whether APL 2020 specifies a default mismatch rule or leaves it to each interpreter. Practical verification across target interpreters is required before relying on any behavior.

What should ⍴ do when total element counts differ between source and target shape?
Is an error, truncation, or zero-padding the intended default for APL 2020?
Does a negative or zero dimension change the mismatch policy?

Tasadduq Burney · Answer

The Nature of the Mismatch
The reshape operation is designed to map a flat sequence into a specific shape. If the total number of elements in the source array is not equal to the product of the requested dimensions, the interpreter must decide how to handle the remainder or the deficit. In modern environments, this typically manifests in three ways:

Error Raising: Most strict interpreters will throw a size mismatch error if the source count cannot be perfectly divided into the target dimensions.
  Truncation: Some legacy or specialized interpreters may truncate the source array to fit the target shape, potentially losing data without warning.
  Padding: Rarely, some environments might pad the result with zeros to fill the required shape count.

Version Assumptions and Uncertainty
It is important to note that while APL 2020 refined aspects of array operations, it does not mandate a single universal policy for all mismatches. Older versions (pre-2020) may not support negative dimensions in the reshape operator at all, resulting in syntax errors rather than runtime logic errors. We assume you are using an interpreter compliant with APL 2020 where negative dimensions are used to calculate remaining space.
Verification and Resolution
To ensure your code is robust across different APL interpreters, follow these diagnostic steps:

Calculate the Product: Multiply the dimensions of your target shape. If this product is not a divisor of the source array length, you must handle the remainder explicitly.
  Test Negative Dimensions: Use a negative dimension to let the interpreter calculate the remaining size. For example, (1 2 3 4)⍴ 2 -1 should result in a 2x2 matrix.
  Verify Zero-Dimension Behavior: Test if a zero in the target shape correctly returns an empty array of the specified rank or if it triggers an error in your specific deployment.

If your environment silently truncates data, it is highly recommended to implement a manual check using the ⍴ function before calling ⍴ to ensure data integrity.

APL 2020 ⍴ reshape operator: element-count mismatch handling across interpreters

1 answer

The Nature of the Mismatch

Version Assumptions and Uncertainty

Verification and Resolution

Your perspective belongs here.

0 question comments