| 23 | In SaC, multidimensional arrays are represented by two vectors, the shape and the data vector, where vectors are one dimensional arrays. Scalar values are viewed as 0-dimensional arrays. The function `reshape` takes as first argument a shape vector, as second an array, and creates an array with identical data vector and the given shape vector. For example: |
| 24 | {{{ |
| 25 | reshape ([3,2],[1,2,3,4,5,6]) |
| 26 | }}} |
| 27 | produces a 3 times 2 matrix. |
| 28 | |
26 | | Regular parallel arrays are similar to arrays in SAC, with one major |
27 | | difference: array operations in DPH are fully typed, and consequently, what |
28 | | is called 'shape invariant programming' in SAC works differently in DPH. In particular, in DPH the dimensionality of an array (not its size, however) are encoded in its type. |
| 30 | Regular parallel arrays are similar to arrays in SaC, with one major |
| 31 | difference: SaC employs a mix of static and dynamic type checking, combined with a form of shape inference, whereas we use GHC's type checker to ensure certain domain restrictions are not violated. |
| 32 | |
| 33 | '''Note:''' currently, we are only able to statically check that restrictions regarding the dimensionality of and array are met, but not with respect to the size. SaC is, to a certain extend, able to do so. I still need to check if there are some cases where the DPH approach would statically find some dimensionality bugs where SaC wouldn't - need to check that. |
| 34 | |
| 35 | |
| 36 | array operations in DPH are fully typed, and consequently, what |
| 37 | is called 'shape invariant programming' in SaC works differently in DPH. In particular, in DPH the dimensionality of an array (not its size, however) are encoded in its type. |