In earlier versions of Quasar, the boundary extension modes (such as
'circular) only affected the
To improve transparency, this is has recently changed. This has the consequence that the following get access modes needed to be supported by the runtime:
(no modifier) % =error (default) or zero extension (kernel, device function) safe % zero extension mirror % mirroring near the boundaries circular % circular boundary extension clamped % keep boundary values unchecked % results undefined when reading outside checked % error when reading outside
Implementation details: there is a bit of work involved, because it needs to be done for all data types (
object, …), for different dimensions (
cube), and for both matrix getters / slice accessors. perhaps the reason that you will not see this feature implemented in other programming languages: 5 x 10 x 3 x 2 = 300 combinations (=functions to be written). Luckily the use of generics in C# alleviates the problem, reducing it (after a bit of research) to 6 combinations (!) where each algorithm has 3 generic parameters. Idem for CUDA computation engine.
Note that the modifier
unchecked should be used with care: only when you are 100% sure that the function is working properly and that there are no memory accesses outside the matrix. A good approach is to use
checked first, and when you find out that there never occur any errors, you can switch to
unchecked, in other to gain a little speed-up (typically 20%-30% on memory accesses).
Now I would like to point out that the access modifiers are not part of type of the object itself, as the following example illustrates:
A : mat'circular = ones(10, 10) B = A % boundary access mode: B : mat'circular C : mat'unchecked = A
Here, both B and C will hold a reference to the matrix A. However, B will copy the access modifier from A (through type inference) and C will override the access modifier of A. The result is that the access modifiers for A, B and C are circular, circular and unchecked, respectively. Even though there is only one matrix involved, there are effectively two ways of accessing the data in this matrix.
Now, to make things even more complicated, there are also put access modes. But for implementation complexity reasons (and more importantly, to avoid unforeseen data races in parallel algorithms), the number of options have been reduced to three:
safe (default) % ignore writing outside the boundaries unchecked % writing outside the boundaries = crash! checked % error when writing outside the boundaries
This means that
'clamped are mapped to
'safe when writing values to the matrix. For example:
A : vec'circular = [1, 2, 3] A[-1] = 0 % Value neglected
The advantage will then be that you can write code such as:
A : mat'circular = imread("lena_big.tif")[:,:,1] B = zeros(size(A)) B[-127..128,-127..128] = A[-127..128,-127..128]