Restructures the object y into a shape of x, keeping its values intact. For simple objects like an Array, this simply amounts to a reshape. However, for more complex objects such as an ArrayPartition, not all of the structural information is adequately contained in the type for standard tools to work. In these cases, restructure gives a way to convert for example an Array into a matching ArrayPartition.
It is a form of vec which is safe for all values in vector spaces, i.e., if it is already a vector, like an AbstractVector or Number, it will return said AbstractVector or Number.
Restructures the object y into a shape of x, keeping its values intact. For simple objects like an Array, this simply amounts to a reshape. However, for more complex objects such as an ArrayPartition, not all of the structural information is adequately contained in the type for standard tools to work. In these cases, restructure gives a way to convert for example an Array into a matching ArrayPartition.
It is a form of vec which is safe for all values in vector spaces, i.e., if it is already a vector, like an AbstractVector or Number, it will return said AbstractVector or Number.
If one is looking for an interface which includes functionality for statically-computed values, see StaticArrayInterface.jl. This was separated from ArrayInterface.jl because it includes a lot of functionality that does not give substantive improvements to the interface, and is likely to be deprecated in the near future as the compiler matures to automate a lot of its optimizations.
Settings
This document was generated with Documenter.jl version 1.5.0 on Monday 19 August 2024. Using Julia version 1.10.4.
+ArrayInterface.jl: An Extended Array Interface for Julia Generic Programming · ArrayInterface.jl
If one is looking for an interface which includes functionality for statically-computed values, see StaticArrayInterface.jl. This was separated from ArrayInterface.jl because it includes a lot of functionality that does not give substantive improvements to the interface, and is likely to be deprecated in the near future as the compiler matures to automate a lot of its optimizations.
Settings
This document was generated with Documenter.jl version 1.6.0 on Sunday 1 September 2024. Using Julia version 1.10.5.
The following traits allow for one to accurately determine the type of indexing allowed on arrays in order to write optimal code for generic array types.
Returns true if the function f is guaranteed to be compatible with LoopVectorization.@avx for supported element and array types. While a return value of false does not indicate the function isn't supported, this allows a library to conservatively apply @avx only when it is known to be safe to do so.
function mymap!(f, y, args...)
+Julia's Extended Array Indexing Interface · ArrayInterface.jl
The following traits allow for one to accurately determine the type of indexing allowed on arrays in order to write optimal code for generic array types.
Returns true if the function f is guaranteed to be compatible with LoopVectorization.@avx for supported element and array types. While a return value of false does not indicate the function isn't supported, this allows a library to conservatively apply @avx only when it is known to be safe to do so.
function mymap!(f, y, args...)
if can_avx(f)
@avx @. y = f(args...)
else
@. y = f(args...)
end
-end
Returns true if all instances of type T are composed of a unique set of elements. This does not require that T subtypes AbstractSet or implements the AbstractSet interface.
Returns true if all instances of type T are composed of a unique set of elements. This does not require that T subtypes AbstractSet or implements the AbstractSet interface.
Is it safe to ivdep arrays of type T? That is, would it be safe to write to an array of type T in parallel? Examples where this is not true are BitArrays or view(rand(6), [1,2,3,1,2,3]). That is, it is not safe whenever different indices may alias the same memory.
Is it safe to ivdep arrays containing elements of type T? That is, would it be safe to write to an array full of T in parallel? This is not true for mutable structs in general, where editing one index could edit other indices. That is, it is not safe when different instances may alias the same memory.
Indicates the most efficient way to access elements from the collection in low-level code. For GPUArrays, will return ArrayInterface.GPU(). For AbstractArray supporting a pointer method, returns ArrayInterface.CPUPointer(). For other AbstractArrays and Tuples, returns ArrayInterface.CPUIndex(). Otherwise, returns nothing.
These are generic functions for forced "allowed indexing". For example, with CUDA.jl's CuArrays a mode can be enabled such that allowscalar(false) forces errors to be thrown if a GPU array is scalar indexed. Instead of using the CUDA-specific CUDA.@allowscalar on an operation, these functions allow for a general generic "allowed indexing" for all array types.
Subtypes of ArrayIndex represent series of transformations for a provided index to some buffer which is typically accomplished with square brackets (e.g., buffer[index[inds...]]). The only behavior that is required of a subtype of ArrayIndex is the ability to transform individual index elements (i.e. not collections). This does not guarantee bounds checking or the ability to iterate (although additional functionality may be provided for specific types).
Is it safe to ivdep arrays of type T? That is, would it be safe to write to an array of type T in parallel? Examples where this is not true are BitArrays or view(rand(6), [1,2,3,1,2,3]). That is, it is not safe whenever different indices may alias the same memory.
Is it safe to ivdep arrays containing elements of type T? That is, would it be safe to write to an array full of T in parallel? This is not true for mutable structs in general, where editing one index could edit other indices. That is, it is not safe when different instances may alias the same memory.
Indicates the most efficient way to access elements from the collection in low-level code. For GPUArrays, will return ArrayInterface.GPU(). For AbstractArray supporting a pointer method, returns ArrayInterface.CPUPointer(). For other AbstractArrays and Tuples, returns ArrayInterface.CPUIndex(). Otherwise, returns nothing.
These are generic functions for forced "allowed indexing". For example, with CUDA.jl's CuArrays a mode can be enabled such that allowscalar(false) forces errors to be thrown if a GPU array is scalar indexed. Instead of using the CUDA-specific CUDA.@allowscalar on an operation, these functions allow for a general generic "allowed indexing" for all array types.
Subtypes of ArrayIndex represent series of transformations for a provided index to some buffer which is typically accomplished with square brackets (e.g., buffer[index[inds...]]). The only behavior that is required of a subtype of ArrayIndex is the ability to transform individual index elements (i.e. not collections). This does not guarantee bounds checking or the ability to iterate (although additional functionality may be provided for specific types).
GetIndex(buffer) = GetIndex{true}(buffer)
GetIndex{check}(buffer) -> g
Wraps an indexable buffer in a function type that is indexed when called, so that g(inds..) is equivalent to buffer[inds...]. If check is false, then all indexing arguments are considered in-bounds. The default value for check is true, requiring bounds checking for each index.
Passing false as check may result in incorrect results/crashes/corruption for out-of-bounds indices, similar to inappropriate use of @inbounds. The user is responsible for ensuring this is correctly used.
SetIndex!(buffer) = SetIndex!{true}(buffer)
SetIndex!{check}(buffer) -> g
Wraps an indexable buffer in a function type that sets a value at an index when called, so that g(val, inds..) is equivalent to setindex!(buffer, val, inds...). If check is false, then all indexing arguments are considered in-bounds. The default value for check is true, requiring bounds checking for each index.
Passing false as check may result in incorrect results/crashes/corruption for out-of-bounds indices, similar to inappropriate use of @inbounds. The user is responsible for ensuring this is correctly used.
These functions allow for the construction of matrices from array information in a generic way. It handles cases like how if x is a vector on the GPU, its associated matrix type should also be GPU-based, and thus appropriately placed with zeros/undef values.
Creates the zero'd matrix version of u. Note that this is unique because similar(u,length(u),length(u)) returns a mutable type, so it is not type-matching, while fill(zero(eltype(u)),length(u),length(u)) doesn't match the array type, i.e., you'll get a CPU array from a GPU array. The generic fallback is u .* u' .* false, which works on a surprising number of types, but can be broken with weird (recursive) broadcast overloads. For higher-order tensors, this returns the matrix linear operator type which acts on the vec of the array.
Creates the matrix version of u with possibly undefined values. Note that this is unique because similar(u,length(u),length(u)) returns a mutable type, so it is not type-matching, while fill(zero(eltype(u)),length(u),length(u)) doesn't match the array type, i.e., you'll get a CPU array from a GPU array. The generic fallback is u .* u', which works on a surprising number of types, but can be broken with weird (recursive) broadcast overloads. For higher-order tensors, this returns the matrix linear operator type which acts on the vec of the array.
These functions allow for generating the instance of a factorization's result without running the full factorization. This thus allows for building types to hold the factorization without having to perform expensive extra computations.
These functions allow for the construction of matrices from array information in a generic way. It handles cases like how if x is a vector on the GPU, its associated matrix type should also be GPU-based, and thus appropriately placed with zeros/undef values.
Creates the zero'd matrix version of u. Note that this is unique because similar(u,length(u),length(u)) returns a mutable type, so it is not type-matching, while fill(zero(eltype(u)),length(u),length(u)) doesn't match the array type, i.e., you'll get a CPU array from a GPU array. The generic fallback is u .* u' .* false, which works on a surprising number of types, but can be broken with weird (recursive) broadcast overloads. For higher-order tensors, this returns the matrix linear operator type which acts on the vec of the array.
Creates the matrix version of u with possibly undefined values. Note that this is unique because similar(u,length(u),length(u)) returns a mutable type, so it is not type-matching, while fill(zero(eltype(u)),length(u),length(u)) doesn't match the array type, i.e., you'll get a CPU array from a GPU array. The generic fallback is u .* u', which works on a surprising number of types, but can be broken with weird (recursive) broadcast overloads. For higher-order tensors, this returns the matrix linear operator type which acts on the vec of the array.
These functions allow for generating the instance of a factorization's result without running the full factorization. This thus allows for building types to hold the factorization without having to perform expensive extra computations.
Many routines require calculating the coloring of a matrix, such as for sparse differentation. The matrix_colors function is the high level function which returns a color vector Vector{Int} with the column colors. This function is overloaded for many special matrix types with analytical solutions for the matrix colors.
Many routines require calculating the coloring of a matrix, such as for sparse differentation. The matrix_colors function is the high level function which returns a color vector Vector{Int} with the column colors. This function is overloaded for many special matrix types with analytical solutions for the matrix colors.
The following functions make it easier to handle array wrappers, such as Adjoint, which can obscure an underlying array's properties under a layer of indirection.
Returns true if the type T wraps another data type and does not alter any of its standard interface. For example, if T were an array then its size, indices, and elements would all be equivalent to its wrapped data.
The following functions make it easier to handle array wrappers, such as Adjoint, which can obscure an underlying array's properties under a layer of indirection.
Returns true if the type T wraps another data type and does not alter any of its standard interface. For example, if T were an array then its size, indices, and elements would all be equivalent to its wrapped data.